One document matched: draft-ietf-xrblock-rtcp-xr-qoe-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2250 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2250.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc3357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3357.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5216 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY rfc5247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY I-D.ietf-avt-rapid-rtp-sync PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rapid-rtp-sync.xml">
<!ENTITY I-D.ietf-pmol-metrics-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pmol-metrics-framework.xml">
<!ENTITY I-D.hunt-avt-monarch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hunt-avt-monarch.xml">
<!ENTITY I-D.ietf-avt-rtp-svc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtp-svc.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="std" docName="draft-ietf-xrblock-rtcp-xr-qoe-08"
ipr="trust200902">
<front>
<title abbrev="RTCP XR QoE Report Blocks">RTP Control Protocol (RTCP)
Extended Report (XR) Blocks for QoE Metric Reporting</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization abbrev="Telchemy">Telchemy Incorporated</organization>
<address>
<postal>
<street>2905 Premiere Parkway, Suite 280</street>
<city>Duluth</city>
<region>GA</region>
<code>30097</code>
<country>USA</country>
</postal>
<email>alan.d.clark@telchemy.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Roland Schott" initials="R." surname="Schott">
<organization abbrev="Deutsche Telekom">Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich-Hertz-Straße 3-7</street>
<street></street>
<city>Darmstadt</city>
<code>64295</code>
<country>Germany</country>
</postal>
<email>Roland.Schott@telekom.de</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>77/440 Soi Phoomjit, Rama IV Road</street>
<street>Phra Khanong, Khlong Toie</street>
<city>Bangkok</city>
<code>10110</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87 502 4274</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2013" />
<abstract>
<t>This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block including two new segment types and associated SDP parameters
that allow the reporting of QoE metrics for use in a range of RTP
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="QoE Metrics Report Block">
<t>This document defines a new block type to augment those defined in
<xref target="RFC3611"></xref>, for use in a range of RTP
applications. <vspace blankLines="1" />The new block type provides
information on media quality using one of several standard
metrics.<vspace blankLines="1" />The metrics belong to the class of
application level metrics defined in <xref
target="RFC6792"></xref>.</t>
</section>
<section title="RTCP and RTCP XR Reports">
<t>The use of RTCP for reporting is defined in <xref
target="RFC3550"></xref>. <xref target="RFC3611"></xref> defined an
extensible structure for reporting using an RTCP Extended Report (XR).
This draft defines a new Extended Report block for use with <xref
target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
</section>
<section title="Performance Metrics Framework">
<t>The Performance Metrics Framework <xref target="RFC6390"></xref>
provides guidance on the definition and specification of performance
metrics. The RTP Monitoring Architectures <xref
target="RFC6792"></xref> provides guideline for reporting block format
using RTCP XR. The XR Block described in this document are in
accordance with the guidelines in <xref target="RFC6390"></xref> and
<xref target="RFC6792"></xref>.</t>
</section>
<section title="Applicability">
<t>The QoE Metrics Report Block can be used in any application of RTP
for which QoE measurement algorithms are defined.</t>
<t>The factors that affect real-time Audio/Video application quality
can be split into two categories. The first category consists of
transport- dependent factors such as packet loss, delay and jitter
(which also translates into losses in the playback buffer). The
factors in the second category are application-specific factors that
affect real time application (e.g., video) quality and are sensitivity
to network errors. These factors can be but not limited to video codec
and loss recovery technique, coding bit rate, packetization scheme,
and content characteristics.</t>
<t>Compared with application-specific factors, the transport-dependent
factors sometimes are not sufficient to measure real time media
quality, since the ability to analyze the real time media in the
application layer provides quantifiable measurements for subscriber
Quality of Experience (QoE) that may not be captured in the
transmission layers or from the RTP layer down. In a typical scenario,
monitoring of the transmission layers can produce statistics
suggesting that quality is not an issue, such as the fact that network
jitter is not excessive. However, problems may occur in the service
layers leading to poor subscriber QoE. Therefore monitoring using only
network-level measurements may be insufficient when application layer
media quality is required.</t>
<t>In order to provide accurate measures of real time media quality
when transporting real time media across a network, the QoE Metrics is
highly required which can be conveyed in the RTCP XR packets [RFC3611]
and may have the following three benefits: <vspace
blankLines="1" /><list style="symbols">
<t>Tuning the content encoder algorithm to satisfy real time data
quality requirements.</t>
<t>Determining which system techniques to use in a given situation
and when to switch from one technique to another as system
parameters change.</t>
<t>Verifying the continued correct operation of an existing
system.</t>
</list></t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>The terminology used is <vspace blankLines="1" /><list>
<t>Numeric formats S X:Y<vspace blankLines="1" /><list>
<t>where S indicates a two's complement signed representation,
X the number of bits prior to the decimal place and Y the
number of bits after the decimal place.</t>
<t>Hence 8:8 represents an unsigned number in the range 0.0 to
255.996 with a granularity of 0.0039. S7:8 would represent the
range -127.996 to +127.996. 0:16 represents a proper binary
fraction with range</t>
<t>0.0 to 1 - 1/65536 = 0.9999847</t>
<t>though note that use of flag values at the top of the
numeric range slightly reduces this upper limit. For example,
if the 16- bit values 0xfffe and 0xffff are used as flags for
"over-range" and "unavailable" conditions, a 0:16 quantity has
range</t>
<t>0.0 to 1 - 3/65536 = 0.9999542</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="SMQM" title="QoE Metrics Block">
<t>Multimedia application QoE metric is commonly expressed as a MOS
("Mean Opinion Score"), MOS is on a scale from 1 to 5, in which 5
represents excellent and 1 represents unacceptable. MOS scores are
usually obtained using subjective testing or using objective algorithm.
However Subjective testing to estimate the multimedia quality may be not
suitable for measuring the multimedia quality since the results may vary
from test to test. Therefore using objective algorithm to calculate MOS
scores is recommended. ITU-T recommendations define the methodologies
for assessment of the performance of multimedia stream <xref
target="G.107"></xref><xref target="P.564"></xref><xref
target="G.1082"></xref><xref target="P.1201.1"></xref><xref
target="P.1201.2"></xref><xref target="P.1202.1"></xref><xref
target="P.NBAMS-HR"></xref> and provides a method to evaluate QoE
estimation algorithms and objective model for video and audio. Hence
this document recommends vendors and implementers to use these
International Telecommunication Union (ITU)-specified methodologies to
measure parameters when possible. <vspace blankLines="1" /></t>
<t>This block reports the multimedia application performance or media
quality beyond the information carried in the standard RTCP packet
format. Information is recorded about QoE metric which provides a
measure that is indicative of the user's view of a service. The
measurement of metrics in this block are usually made at the receiving
end of the RTP stream. Instances of this Metrics Block refer by
Synchronization source (SSRC) to the separate auxiliary Measurement
Information block <xref target="RFC6776"></xref> which describes
measurement periods in use (see RFC6776 section 4.2).</t>
<t>This Metrics Block relies on the measurement period in the
Measurement Information block indicating the span of the report. Senders
MUST send this block in the same compound RTCP packet as the measurement
information block. Receivers MUST verify that the measurement period is
received in the same compound RTCP packet as this Metrics Block. If not,
this Metrics Block MUST be discarded.</t>
<section title="Metric Block Structure">
<t>The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to be
reported in each block. Flags indicate which are and which are not
reported. The fields corresponding to unreported parameters MUST be
present, but are set to zero. The receiver MUST ignore any QoE Metrics
Block with a non-zero value in any field flagged as unreported. The
encoding of QoE metrics block payload consists of a series of 32 bit
units called segments that describe MOS Type, MoS algorithm and MoS
value.<vspace blankLines="1" /></t>
<t>The QoE Metrics Block has the following format: <figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=QMB | I | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
..................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Definition of Fields in QoE Metrics Block">
<t><list style="hanging">
<t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />The
QoE Metrics Block is identified by the constant <QMB>.
<vspace blankLines="1" /></t>
<t hangText="Interval Metric flag (I): 2 bits"><vspace
blankLines="1" />This field is used to indicate whether the QoE
metrics are Sampled, Interval or Cumulative metrics <xref
target="RFC6792"></xref>: <vspace blankLines="1" /><list>
<t>I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between successive
metrics reports.</t>
<t>I=11: Cumulative Duration - the reported value applies to
the accumulation period characteristic of cumulative
measurements.</t>
<t>I=01: Sampled Value - the reported value is a sampled
instantaneous value.</t>
</list><vspace blankLines="1" />In this document, the value I=00
is reserved for future use. Senders MUST NOT use the values I=00.
If a block is received with I=00, the receiver MUST discard the
block. <vspace blankLines="1" /></t>
<t hangText="Reserved: 6 bits"><vspace blankLines="1" />This field
is reserved for future definition. In the absence of such a
definition, the bits in this field MUST be set to zero and ignored
by the receiver (See RFC6709 section 4.2). <vspace
blankLines="1" /></t>
<t hangText="Block Length: 16 bits"><vspace blankLines="1" />The
length of this report block in 32-bit words, minus one. For the
QoE Metrics Block, the block length is variable length.<vspace
blankLines="1" /></t>
<t hangText="SSRC of source: 32 bits"><vspace blankLines="1" /> As
defined in Section 4.1 of <xref target="RFC3611"></xref>. <vspace
blankLines="1" /></t>
<t hangText="Segment i: 32 bits"><vspace blankLines="1" />There
are two segment types defined in this document: single stream
Audio/Video per SSRC segment, multi-channel audio per SSRC
segment. Multi-channel audio per SSRC segment is used to deal with
the case where Multi-channel audios are carried in one RTP stream
while single stream Audio/Video per SSRC segment is used to deal
with the case where each media stream is identified by SSRC and
sent in separate RTP stream. The leftmost bit of the segment
determines its type. If the leftmost bit of the segment is zero,
then it is single stream segment. If the leftmost bit is one, then
it is multi-channel audio segment. Note that two segment types can
not be present in the same metric block. <vspace
blankLines="1" /></t>
</list></t>
<section title="Single Stream Audio/Video per SSRC Segment">
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Segment Type (S): 1 bit"><vspace
blankLines="1" />This field is used to identify the segment type
used in this report block. A zero identifies this as a single
stream Audio/Video per SSRC segment. Single stream means there
is only one media stream carried in one RTP stream. The single
stream Audio/Video per SSRC segment can be used to report the
MoS value associated with the media stream identified by SSRC.
If there are multiple media streams and they want to use the
single stream Audio/Video per SSRC segment to report the MOS
value, they should be carried in the separate RTP streams with
each identified by different SSRC. In this case, multiple QoE
Metrics Blocks are required to report the MOS value
corresponding to each media stream using single stream
Audio/Video per SSRC segment in the same RTCP XR packet. <vspace
blankLines="1" /></t>
<t hangText="Calg Algorithm ID (CAID) : 8bits"><vspace
blankLines="1" />The 8-bit CAID is the local identifier of
calculation algorithm associated with this segment in the range
1-255 inclusive. <vspace blankLines="1" /></t>
<t hangText="Payload Type (PT): 7 bits"><vspace
blankLines="1" />QoE metrics reporting depends on the payload
format in use. This field identifies the format of the RTP
payload. For RTP sessions where multiple payload formats can be
negotiated or the payload format changes during the
mid-session), the value of this field will be used to indicate
what payload format was in use for the reporting interval.
<vspace blankLines="1" /></t>
<t hangText="MOS Value: 16 bits"><vspace blankLines="1" />The
estimated mean opinion score for multimedia application
performance is defined as including the effects of delay,loss,
discard,jitter and other effects that would affect media
quality. It is expressed in numeric format 8:8 with the value in
the range 0.0 to 255.996. The valid the measured value ranges
from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the
measured value is over ranged, the value 0xFFFE MUST be reported
to indicate an over-range measurement. If the measurement is
unavailable, the value 0xFFFF MUST be reported. Values other
than 0xFFFE,0xFFFF and the valid range defined above MUST NOT be
sent and MUST be ignored by the receiving system. <vspace
blankLines="1" /></t>
</list></t>
</section>
<section title="Multi-Channel audio per SSRC Segment">
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| CAID | PT |CHID | MOS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Segment Type (S): 1 bit"><vspace
blankLines="1" />This field is used to identify the segment type
used in this report block. A one identifies this as a
multi-channel audio segment. <vspace blankLines="1" /></t>
<t hangText="CAlg Algorithm ID (CAID) : 8bits"><vspace
blankLines="1" />The 8-bit ID is the local identifier of this
segment in the range 1-255 inclusive. <vspace
blankLines="1" /></t>
<t hangText="Payload Type (PT): 7 bits"><vspace
blankLines="1" />As defined in Section 3.2.1 of this
document.<vspace blankLines="1" /></t>
<t hangText="Channel Identifier (CHID): 3 bits"><vspace
blankLines="1" />If multiple channels of audio are carried in
one RTP stream, each channel of audio will be viewed as a
independent channel(e.g., left channel audio, right channel
audio). This field is used to identify each channel carried in
the same media stream. The default Channel mapping follows
static ordering rule described in the section 4.1 of <xref
target="RFC3551"></xref>. However there are some payload formats
that use different channel mappings, e.g., AC-3 audio over RTP
<xref target="RFC4184"></xref> only follow AC-3 channel order
scheme defined in <xref target="ATSC"></xref>. Enhanced AC-3
Audio over RTP <xref target="RFC4598"></xref> uses dynamic
channel transform mechanism. In order that the appropriate
channel mapping can be determined, QoE reports need to be tied
to an RTP payload format, i.e., including the payload type of
the reported media according to <xref target="RFC6792"></xref>
and using Payload Type to determine the appropriate channel
mapping. <vspace blankLines="1" /></t>
<t hangText="MOS Value: 13 bits"><vspace blankLines="1" />The
estimated mean opinion score for multimedia application
performance is defined as including the effects of delay,loss,
discard,jitter and other effects that would affect multimedia
quality . It is expressed in numeric format 6:7 with the value
in the range 0.0 to 63.992. The valid the measured value ranges
from 0.0 to 50.0, corresponding to MoS x 10 as for MoS. If the
measured value is over ranged, the value 0x1FFE MUST be reported
to indicate an over-range measurement. If the measurement is
unavailable, the value 0x1FFF MUST be reported. Values other
than 0x1FFE,0x1FFF and the valid range defined above MUST NOT be
sent and MUST be ignored by the receiving system. <vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
</section>
<section title="SDP Signaling">
<t><xref target="RFC3611"></xref> defines the use of SDP (Session
Description Protocol) <xref target="RFC4566"></xref> for signaling the
use of XR blocks. However XR blocks MAY be used without prior signaling
(see section 5 of RFC3611).</t>
<section title="SDP rtcp-xr-attrib Attribute Extension">
<t>This section augments the SDP <xref target="RFC4566"></xref>
attribute "rtcp-xr" defined in <xref target="RFC3611"></xref> by
providing an additional value of "xr-format" to signal the use of the
report block defined in this document. Within the "xr-format", the
syntax element "extmap" is an attribute as defined in <xref
target="RFC4566"></xref> and used to signal the mapping of the local
identifier (CAID) in the segment extension defined in section 3.2 to
the calculation algorithm. Specific extensionattributes are defined by
the specification that defines a specific extension name; there may be
several.</t>
<figure>
<artwork>
xr-format =/ xr-qoe-block
xr-qoe-block = "qoe-metrics" ["=" extmap *("," extmap)]
extmap = mapentry "=" extensionname [SP extentionattributes]
direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
mapentry = "calg:" 1*5 DIGIT ["/" direction]
extensionname = "P564";ITU-T P.564 Compliant Algorithm [P.564]
/ "G107";ITU-T G.107 [G.107]
/ "TS101_329";ETSI TS 101 329-5 Annex E [ ETSI]
/"JJ201_01 ";TTC JJ201.01 [TTC]
/"P1201_01";ITU-T P.1201.2 [P.1201.1]
/"P1201_02";ITU-T P.1201.2 [P.1201.2]
/"P1202_01";ITU-T P.1202.1 [P.1202.1]
/"P1202_02";ITU-T P. NBAMS-HR [P.NBAMS-HR]
/ non-ws-string
extentionattributes = mosref
/attributes-ext
mosref = "mosref=" ("l"; lower resolution
/ "h";higher resolution
/ "lh”;both lower resolution and
;high resolution are supported
/ non-ws-string
attributes-ext = non-ws-string
SP = <Define in RFC5234>
non-ws-string = 1*(%x21-FF)
</artwork>
</figure>
<t>Each local identifier (CAID)of calculation algorithm used in the
segment defined in the section 3.2 is mapped to a string using an
attribute of the form: <figure>
<artwork>
a=extmap:<value> ["/"<direction>] <name> [<extensionattributes>]
</artwork>
</figure></t>
<t>where <name> is a calculation algorithm name, as above,
<value> is the local identifier (CAID)of the calculation
algorithm associated with the segment defined in this document and is
an integer in the valid range inclusive. <figure>
<artwork>
Example:
a = rtcp-xr:qoe-metrics = calg:1=G107,calg:2=P1202.1
</artwork>
</figure></t>
<t>A usable mapping MUST use IDs in the valid range, and each ID in
this range MUST be unique and used only once for each stream or each
channel in the stream.</t>
<t>The mapping MUST be provided per media stream (in the media-level
section(s) of SDP, i.e., after an "m=" line).</t>
<t>The syntax element "mosref" is referred to the media
resolution(e.g., Narrowband (3.4kHz) Speech and Standard Definition
(SD) Resolution Video with lower resolution, Wideband (7kHz) Speech
and High Definition (HD) Resolution Video with higher resolution). MOS
scores reported in the QoE block may vary with the MoS reference; For
example MOS values for narrowband, wideband codecs occupy the same
range but should be reported in different value. For video
application, MoS scores for SD resolution, HD resolution video also
occupy the same ranges and should be reported in different value. </t>
</section>
<section title="Offer/Answer Usage">
<t>When SDP is used in offer-answer context, the SDP Offer/Answer
usage defined in [RFC3611] applies. In the offer answer context, the
signaling described above may be used in three ways: <vspace
blankLines="1" /><list style="symbols">
<t>asymmetric behavior (segment extensions sent in only one
direction),</t>
<t>the offer of mutually exclusive alternatives, or</t>
<t>the offer of more segments than can be sent in a single
session.</t>
</list></t>
<t>A direction attribute MAY be included in an extmap; without it, the
direction implicitly inherits, of course, from the RTCP stream
direction.</t>
<t>Segment extension, with their directions, may be signaled for an
"inactive" stream. It is an error to use an extension direction
incompatible with the stream direction (e.g., a "sendonly" attribute
for a "recvonly" stream).</t>
<t>If an segment extension is offered as "sendrecv", explicitly or
implicitly, and asymmetric behavior is desired, the SDP may be
modified to modify or add direction qualifiers for that segment
extension.</t>
<t>A mosref attribute MAY be included in an extmap; without it, the
mosref implicitly inherits, of course, from the name attribute (e.g.,
P.1201.1 [P.1201.1] indicates lower resolution used while P.1201.2
[P.1201.2] indicates higher resolution used) or payload type carried
in the segment extension (e.g.,EVRC-WB [RFC5188] indicates using
Wideband Codec). However not all payload types or MoS algorithm names
indicates resolution to be used. </t>
<t>If an segment extension is offered as "lh", explicitly, and
asymmetric behavior is desired, the SDP may be modified to modify
mosref attribute value for that segment extension. </t>
<t>If an answerer receives an offer with an mosref attribute value it
doesn’t support (e.g.,the answerer only supports “l” and receives
“h”from offerer), the answer should reject the mosref attribute value
offered by the offerer. </t>
<t>If the answerer wishes to reject a mosref attribute offered by the
offerer, it sets identifiers associated with segment extensions in the
answer to the value in the range 4096-4351. The rejected answer MUST
contain 'mosref ' attribute whose value is the value of the SDP
offer.</t>
<t>Local identifiers in the valid range inclusive in an offer or
answer must not be used more than once per media section. A session
update MAY change the direction qualifiers of segment extensions under
use. A session update MAY add or remove segment extension(s).
Identifiers values in the valid range MUST NOT be altered
(remapped).</t>
<t>If a party wishes to offer mutually exclusive alternatives, then
multiple segment extensions with the same identifier in the (unusable)
range 4096-4351 may be offered; the answerer should select at most one
of the offered extensions with the same identifier, and remap it to a
free identifier in the valid range, for that extension to be usable.
Note that two segment types defined in section 3 are also two
exclusive alternatives.</t>
<t>If more segment extensions are offered in the valid range, the
answerer should choose those that are desired, and place the offered
identifier value "as is" in the SDP answer.</t>
<t>Similarly, if more segment extensions are offered than can be fit
in the valid range, identifiers in the range 4096-4351 may be offered;
the answerer should choose those that are desired, and remap them to a
free identifier in the valid range.</t>
<t>Note that the range 4096-4351 for these negotiation identifiers is
deliberately restricted to allow expansion of the range of valid
identifiers in future. Segment extensions with an identifier outside
the valid range cannot, of course, be used. <figure>
<artwork>
Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc.
all omitted for brevity):
The offer:
</artwork>
</figure>a=rtcp-xr:qoe-metrics=calg:4906=P1201.1l,calg:4906=P1202.1l,calg:4907=G107
</t>
<t>The answerer is interested in transmission P.1202.1 on lower
resolution application, but doesn't support P.1201.1 on lower
resolution application at all. It is interested in transmission G.107.
It therefore adjusts the declarations: </t>
<t>a=rtcp-xr:qoe-metrics=calg:1=P1202.1l, calg:2=G107</t>
</section>
</section>
<section title="IANA Considerations">
<t>New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to <xref
target="RFC3611"></xref>.</t>
<section title="New RTCP XR Block Type value">
<t>This document assigns the block type value QMB in the IANA "RTCP XR
Block Type Registry" to the "QoE Metrics Block".</t>
<t>[Note to RFC Editor: please replace QMB with the IANA provided RTCP
XR block type for this block.]</t>
</section>
<section title="New RTCP XR SDP Parameter">
<t>This document also registers a new parameter "qoe-metrics" in the
"RTCP XR SDP Parameters Registry".</t>
</section>
<section title="Contact information for registrations">
<t>The contact information for the registrations is: <figure
align="center">
<artwork>
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012 China
</artwork>
</figure></t>
</section>
<section title="New registry of calculation algorithms">
<t>This document creates a new registry to be called "RTCP XR QoE
metric block - multimedia application Calculation Algorithm" as a sub-
registry of the "RTP Control Protocol Extended Reports (RTCP XR) Block
Type Registry". This registry applies to the multimedia session where
each type of media are sent in a separate RTP stream and also applies
to the session where Multi-channel audios are carried in one RTP
stream. Policies for this new registry are as follows: <vspace
blankLines="1" /><list style="symbols">
<t>The information required to support this assignment is an
unambiguous definition of the new metric, covering the base
measurements and how they are processed to generate the reported
metric. <vspace blankLines="1" /></t>
<t>The review process for the registry is "Specification Required"
as described in Section 4.1 of <xref
target="RFC5226"></xref>.<vspace blankLines="1" /></t>
<t>Entries in the registry are identified by entry name and mapped
to the local identifier (CAID) in the segment extension defined in
section 3.2.<vspace blankLines="1" /></t>
<t>Registration Template<vspace blankLines="1" />The following
information must be provided with each registration:<list>
<t>Name: A string uniquely and unambiguously identifying the
Calculation algorithm for use in protocols.</t>
<t>Name Description: A valid Description of the Calculation
algorithm name.</t>
<t>Reference: The reference which defines the calculation
algorithm corresponding to the Name and Name Description.</t>
<t>Type: The media type to which the calculation algorithm is
applied</t>
</list><vspace blankLines="1" /></t>
<t>Initial assignments are as follows:<figure>
<artwork>
Name Name Description Reference Type
========= =================================== ========== ====
P564 ITU-T P.564 Compliant Algorithm [P.564] Voice
G107 ITU-T G.107 [G.107] Voice
TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice
JJ201_01 TTC JJ201.01 [TTC] Voice
P1201_01 ITU-T P.1201.01 [P.1201.1] Multimedia
P1201_02 ITU-T P.1201.02 [P.1201.2] Multimedia
P1202_01 ITU-T P.1202.01 [P.1202.01] Video
P1202_02 ITU-T P. NBAMS-HR [P. NBAMS-HR] Video
</artwork>
</figure></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>The new RTCP XR report blocks proposed in this document introduces no
new security considerations beyond those described in <xref
target="RFC3611"></xref>.</t>
</section>
<section title="Authors">
<t>This draft merges ideas from two drafts addressing the QoE metric
Reporting issue. The authors of these drafts are listed below (in
alphabetical order): <vspace blankLines="1" /><list>
<t>Alan Clark < alan.d.clark@telchemy.com ></t>
<t>Geoff Hunt < r.geoff.hunt@gmail.com ></t>
<t>Martin Kastner < martin.kastner@telchemy.com ></t>
<t>Kai Lee < leekai@ctbri.com.cn ></t>
<t>Roland Schott < roland.schott@telekom.de ></t>
<t>Qin Wu < sunseawq@huawei.com ></t>
<t>Glen Zorn < gwz@net-zen.net ></t>
</list></t>
</section>
<section title="Acknowledgements">
<t>The authors gratefully acknowledge the comments and contributions
made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi
Raviraj, Albrecht Schwarz, Tom Taylor, Bill Ver Steeg, David R Oran, Ali
Begen and Hideaki Yamada.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3611;
<reference anchor="RFC6776">
<front>
<title>Measurement Identity and information Reporting using SDES
item and XR Block</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="RFC" value="6776" />
<format type="TXT" />
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3550" />
<format type="TXT" />
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal
Control</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3551" />
<format type="TXT" />
</reference>
&rfc2119;
&rfc4566;
&rfc5234;
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T.,Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
<format target="http://www.rfc-editor.org/rfc/rfc5226.txt" type="TXT" />
</reference>
<reference anchor="ATSC">
<front>
<title>ATSC Standard: Digital Audio Compression (AC-3), Revision
B</title>
<author>
<organization>U.S. Advanced Television Systems Committee
(ATSC)</organization>
</author>
<date month="June" year="2005" />
</front>
<seriesInfo name="ATSC" value="Doc A/52B" />
</reference>
</references>
<references title="Informative References">
<reference anchor="G.1082">
<front>
<title>Measurement-based methods for improving the robustness of
IPTV performance</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.1082" />
</reference>
<reference anchor="P.564">
<front>
<title>Conformance testing for narrowband Voice over IP transmission
quality assessment models</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.564" />
</reference>
<reference anchor="G.107">
<front>
<title>The E Model, a computational model for use in transmission
planning</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="ITU-T Recommendation" value="G.107" />
</reference>
<reference anchor="ETSI">
<front>
<title>Quality of Service (QoS) measurement methodologies</title>
<author>
<organization>ETSI</organization>
</author>
<date month="November" year="2000" />
</front>
<seriesInfo name="ETSI" value="TS 101 329-5 V1.1.1" />
</reference>
<reference anchor="P.1201.1">
<front>
<title>Parametric non-intrusive assessment of audiovisual media
streaming quality - lower resolution application area</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.1201.1" />
</reference>
<reference anchor="P.1201.2">
<front>
<title>Parametric non-intrusive assessment of audiovisual media
streaming quality - higher resolution application area</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.1201.2" />
</reference>
<reference anchor="P.1202.1">
<front>
<title>Parametric non-intrusive bitstream assessment of video media
streaming quality - lower resolution application area</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.1202.1" />
</reference>
<reference anchor="P.NBAMS-HR">
<front>
<title>Parametric non-intrusive bitstream assessment of video media
streaming quality - higher resolution application area</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.NBAMS-HR" />
</reference>
<reference anchor="TTC">
<front>
<title>A method for speech quality assessment for Voice over
IP</title>
<author>
<organization>TTC 201.01 (Japan)</organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC6792">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<date month="November" year="2012" />
</front>
<seriesInfo name="RFC" value="6792" />
<format type="TXT" />
</reference>
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</reference>
<reference anchor="RFC4598">
<front>
<title>Real-time Transport Protocol (RTP) Payload Format for
Enhanced AC-3 (E-AC-3) Audio</title>
<author fullname="Brian Link" initials="B." surname="Link">
<organization>Dolby Laboratories</organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4598" />
<format target="http://www.rfc-editor.org/rfc/rfc4598.txt" type="TXT" />
</reference>
<reference anchor="RFC4184">
<front>
<title>RTP Payload Format for AC-3 Audio</title>
<author fullname="Brian Link" initials="B." surname="Link">
<organization>Dolby Laboratories</organization>
</author>
<author fullname="Todd Hager" initials="T." surname="Hager">
<organization>Dolby Laboratories</organization>
</author>
<author fullname="Jason Flaks" initials="J." surname="Flaks">
<organization>Microsoft Corporation</organization>
</author>
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4184" />
<format octets="" target="http://www.rfc-editor.org/rfc/rfc4184.txt"
type="TXT" />
</reference>
<reference anchor="RFC5188">
<front>
<title>RTP Payload Format for the Enhanced Variable Rate Wideband
Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec
</title>
<author fullname="H.Desineni" initials="H." surname="Desineni">
<organization></organization>
</author>
<author fullname="Q.Xie" initials="Q." surname="Xie">
<organization></organization>
</author>
<date month="February" year="2008" />
</front>
<seriesInfo name="RFC" value="5188" />
<format octets="" target="http://www.rfc-editor.org/rfc/rfc5188.txt"
type="TXT" />
</reference>
</references>
<section title="Example of User Quality of Experience Evaluation for video stream ">
<t>To evaluate user quality of experience levels using objective test
data, MoS Scores provide a familiar, easily understood numeric
representation of video, audio, and overall audiovisual quality. Unlike
audio, video is even more sensitive to transport impairments , and even
low rates of packet loss can cause severe degradation in perceived
quality. However, all occurrences of packet loss do not have an equal
impact on perceptual quality, in part because of the way video frames
are structured during the encoding process - such as frame properties
including frame type, frame structure and quantization parameter (QP),
and in part due to subjective factors - such as the degree to which
perception is affected by the levels of motion, detail in the video
sequence, and decoder characteristic parameters including media
resolution,codec type. When a video stream is sent from the media source
to RTP receiving end and get monitored. in order to provide accurate
evaluation of video quality, one possible QoE evaluation method is
having network nodes that implement network management tools in place.
They may know frame properties,perception degree, decoder characteristic
parameters of this video stream using some out of band means, gather
transport impairment information received from the RTP receiving end and
use them as MoS calculation input parameters to calculate MoS scores by
choosing appropriate MoS calculation algorithm. Such MoS Scores value
can be useful for troubleshooting or comparing video quality across
different service types.</t>
</section>
<section title="Metrics represented using RFC6390 Template">
<t>RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned.</t>
<t><list style="letters">
<t>MoS Value Metric<vspace blankLines="1" /><list style="symbols">
<t>Metric Name: Mos value<vspace blankLines="1" /></t>
<t>Metric Description: The estimated mean opinion score for
multimedia application performance is defined as including the
effects of delay,loss, discard,jitter and other effects that
would affect multimedia quality. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 3.2.1, MoS
value definition [RFCXXXX]. <vspace blankLines="1" /></t>
<t>Units of Measurement: See section 3.2.1, MoS value definition
[RFCXXXX]. <vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 3, 2nd paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 3, 3rd paragraph [RFCXXXX]
for measurement timing and section 3.1 [RFCXXXX] for Interval
Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>Segment Type Metric<vspace blankLines="1" /><list style="symbols">
<t>Metric Name: Segment Type<vspace blankLines="1" /></t>
<t>Metric Description: It is used to identify the segment type
used in this report block. For more details, see section 3.2.1,
Segment type definition. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 3.2.1,
Segment Type definition [RFCXXXX]. <vspace blankLines="1" /></t>
<t>Units of Measurement: See section 3.2.1, Segment Type
definition [RFCXXXX]. <vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 3, 2nd paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 3, 3rd paragraph [RFCXXXX]
for measurement timing and section 3.1 [RFCXXXX] for Interval
Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>Calg Algorithm Identifier Metric<vspace blankLines="1" /><list
style="symbols">
<t>Metric Name: Calg Algorithm Identifier<vspace
blankLines="1" /></t>
<t>Metric Description: It is the local identifier of calculation
Algorithm associated with this segment in the range 1-255
inclusive. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 3.2.1, Calg
Algorithm ID definition [RFCXXXX]. <vspace blankLines="1" /></t>
<t>Units of Measurement: See section 3.2.1, Calg Algorithm ID
definition[RFCXXXX]. <vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 3, 2nd paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 3, 3rd paragraph [RFCXXXX]
for measurement timing and section 3.1 [RFCXXXX] for Interval
Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>Payload Type Metric<vspace blankLines="1" /><list style="symbols">
<t>Metric Name: Payload Type<vspace blankLines="1" /></t>
<t>Metric Description: It is used to identify the format of the
RTP payload. For more details, see section 3.2.1, payload type
definition. <vspace blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 3.2.1,
Payload type definition [RFCXXXX]. <vspace blankLines="1" /></t>
<t>Units of Measurement: See section 3.2.1, payload type
definition[RFCXXXX]. <vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 3, 2nd paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 3, 3rd paragraph [RFCXXXX]
for measurement timing and section 3.1 [RFCXXXX] for Interval
Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
<t>Channel Identifier Metric<vspace blankLines="1" /><list
style="symbols">
<t>Metric Name: Payload Type<vspace blankLines="1" /></t>
<t>Metric Description: It is used to identify each channel
carried in the same media stream. For more details, see section
3.2.2, channel identifier definition. <vspace
blankLines="1" /></t>
<t>Method of Measurement or Calculation: See section 3.2.2,
Channel Identifier definition [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Units of Measurement: See section 3.2.2, channel identifier
definition[RFCXXXX]. <vspace blankLines="1" /></t>
<t>Measurement Point(s) with Potential Measurement Domain: See
section 3, 2nd paragraph [RFCXXXX]. <vspace
blankLines="1" /></t>
<t>Measurement Timing: See section 3, 3rd paragraph [RFCXXXX]
for measurement timing and section 3.1 [RFCXXXX] for Interval
Metric flag. <vspace blankLines="1" /></t>
<t>Use and applications: See section 1.4 [RFCXXXX].<vspace
blankLines="1" /></t>
<t>Reporting model: See RFC3611.<vspace blankLines="1" /></t>
</list></t>
</list></t>
</section>
<section title="Change Log">
<section title="draft-ietf-xrblock-rtcp-xr-qoe-08">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Remove mostype attribute from SDP extension since it can
inferred from payload type.</t>
<t>Clarify mosref attribute usage in the O/A.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-07">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Some editorial changes to get in line with burst gap related
draft.</t>
<t>Add an appendix to apply RFC6390 template.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-06">
<t>The following are the major changes compared to previous two
versions: <list style="symbols">
<t>A few Contact information update.</t>
<t>A few Acknowledgement section update.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-04">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Split two references P.NAMS and P.NBAMS into four
references.</t>
<t>SDP signaling update.</t>
<t>Add one example to explain User QoE evaluation for video
stream</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-03">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Add one new reference to support TTC JJ201.01.</t>
<t>Update two references P.NAMS and P.NBAMS.</t>
<t>Other Editorial changes based on comments applied to PDV and
Delay drafts.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-02">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Remove leftmost second bit since it is ueeless.</t>
<t>Change 13bits MoS value field into 14 bits to increase MoS
precision.</t>
<t>Fix some typo and make some editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-01">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Remove layered support from the QoE metric draft.</t>
<t>Allocate 7 bits in the block header for payload type to
indicate what type of payload format is in use and add associated
definition of payload type.</t>
<t>Clarify using Payload Type to determine the appropriate channel
mapping in the definition of Channel Identifier.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-qoe-00">
<t>The following are the major changes compared to previous version:
<list style="symbols">
<t>Allocate one more bit in the single stream per SSC segment to
get alignment with the other two segment type.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:12:54 |