rfc9627.original   rfc9627.txt 
Payload Working Group J. Lennox Internet Engineering Task Force (IETF) J. Lennox
Internet-Draft D. Hong Request for Comments: 9627 8x8 / Jitsi
Intended status: Standards Track Vidyo Category: Standards Track D. Hong
Expires: January 11, 2018 J. Uberti ISSN: 2070-1721 Vidyo
J. Uberti
S. Holmer S. Holmer
M. Flodman M. Flodman
Google Google
July 10, 2017 September 2024
The Layer Refresh Request (LRR) RTCP Feedback Message The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-07
Abstract Abstract
This memo describes the RTCP Payload-Specific Feedback Message "Layer This memo describes the RTCP Payload-Specific Feedback Message Layer
Refresh Request" (LRR), which can be used to request a state refresh Refresh Request (LRR), which can be used to request a state refresh
of one or more substreams of a layered media stream. It also defines of one or more substreams of a layered media stream. It also defines
its use with several RTP payloads for scalable media formats. its use with several RTP payloads for scalable media formats.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 11, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9627.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 2. Conventions and Terminology
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology
3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3. Layer Refresh Request
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 3.1. Message Format
3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Semantics
4. Usage with specific codecs . . . . . . . . . . . . . . . . . 8 4. Usage with Specific Codecs
4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. H264 SVC
4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. VP8
4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. H265
5. Usage with different scalability transmission mechanisms . . 11 5. Usage with Different Scalability Transmission Mechanisms
6. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 6. SDP Definitions
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
This memo describes an RTCP [RFC3550] Payload-Specific Feedback This memo describes an RTCP [RFC3550] Payload-Specific Feedback
Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to Message [RFC4585] Layer Refresh Request (LRR). It is designed to
allow a receiver of a layered media stream to request that one or allow a receiver of a layered media stream to request that one or
more of its substreams be refreshed, such that it can then be decoded more of its substreams be refreshed such that it can then be decoded
by an endpoint which previously was not receiving those layers, by an endpoint that previously was not receiving those layers,
without requiring that the entire stream be refreshed (as it would be without requiring that the entire stream be refreshed (as it would be
if the receiver sent a Full Intra Request (FIR); [RFC5104] see also if the receiver sent a Full Intra Request (FIR) [RFC5104]; see also
[RFC8082]). [RFC8082]).
The feedback message is applicable both to temporally and spatially The feedback message is applicable to both temporally and spatially
scaled streams, and to both single-stream and multi-stream scaled streams and to both single-stream and multi-stream scalability
scalability modes. modes.
2. Conventions, Definitions and Acronyms 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Terminology 2.1. Terminology
A "Layer Refresh Point" is a point in a scalable stream after which a A "layer refresh point" is a point in a scalable stream after which a
decoder, which previously had been able to decode only some (possibly decoder, which previously had been able to decode only some (possibly
none) of the available layers of stream, is able to decode a greater none) of the available layers of stream, is able to decode a greater
number of the layers. number of the layers.
For spatial (or quality) layers, in normal encoding, a subpicture can For spatial (or quality) layers, in normal encoding, a subpicture can
depend both on earlier pictures of that spatial layer and also on depend both on earlier pictures of that spatial layer and also on
lower-layer pictures of the current picture. A layer refresh, lower-layer pictures of the current picture. However, a layer
however, typically requires that a spatial layer picture be encoded refresh typically requires that a spatial layer picture be encoded in
in a way that references only the lower-layer subpictures of the a way that references only the lower-layer subpictures of the current
current picture, not any earlier pictures of that spatial layer. picture, not any earlier pictures of that spatial layer.
Additionally, the encoder must promise that no earlier pictures of Additionally, the encoder must promise that no earlier pictures of
that spatial layer will be used as reference in the future. that spatial layer will be used as reference in the future.
However, even in a layer refresh, layers other than the ones being However, even in a layer refresh, layers other than the ones being
refreshed may still maintain dependency on earlier content of the refreshed may still maintain dependency on earlier content of the
stream. This is the difference between a layer refresh and a Full stream. This is the difference between a layer refresh and a FIR
Intra Request [RFC5104]. This minimizes the coding overhead of [RFC5104]. This minimizes the coding overhead of refresh to only
refresh to only those parts of the stream that actually need to be those parts of the stream that actually need to be refreshed at any
refreshed at any given time. given time.
An illustration of spatial layer refresh of an enhancement layer is The spatial layer refresh of an enhancement layer is shown below.
shown below. <-- indicates a coding dependency. The "<--" indicates a coding dependency.
... <-- S1 <-- S1 S1 <-- S1 <-- ... ... <-- S1 <-- S1 S1 <-- S1 <-- ...
| | | | | | | |
\/ \/ \/ \/ \/ \/ \/ \/
... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ...
1 2 3 4 1 2 3 4
Figure 1 Figure 1
In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a
decoder which had previously only been decoding spatial layer S0 decoder that had previously only been decoding spatial layer S0 would
would be able to decode layer S1 starting at frame 3. be able to decode layer S1 starting at frame 3.
An illustration of spatial layer refresh of a base layer is shown The spatial layer refresh of a base layer is shown below. The "<--"
below. <-- indicates a coding dependency. indicates a coding dependency.
... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ...
| | | | | | | |
\/ \/ \/ \/ \/ \/ \/ \/
... <-- S0 <-- S0 S0 <-- S0 <-- ... ... <-- S0 <-- S0 S0 <-- S0 <-- ...
1 2 3 4 1 2 3 4
Figure 2 Figure 2
In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a
decoder which had previously not been decoding the stream at all decoder that had previously not been decoding the stream at all could
could decode layer S0 starting at frame 3. decode layer S0 starting at frame 3.
For temporal layers, while normal encoding allows frames to depend on For temporal layers, while normal encoding allows frames to depend on
earlier frames of the same temporal layer, layer refresh requires earlier frames of the same temporal layer, layer refresh requires
that the layer be "temporally nested", i.e. use as reference only that the layer be "temporally nested", i.e., use as reference only
earlier frames of a lower temporal layer, not any earlier frames of earlier frames of a lower temporal layer, not any earlier frames of
this temporal layer, and also promise that no future frames of this this temporal layer and promise that no future frames of this
temporal layer will reference frames of this temporal layer before temporal layer will reference frames of this temporal layer before
the refresh point. In many cases, the temporal structure of the the refresh point. In many cases, the temporal structure of the
stream will mean that all frames are temporally nested, in which case stream will mean that all frames are temporally nested; in this case,
decoders will have no need to send LRR messages for the stream. decoders will have no need to send LRR messages for the stream.
An illustration of temporal layer refresh is shown below. <-- The temporal layer refresh is shown below. The "<--" indicates a
indicates a coding dependency. coding dependency.
... <----- T1 <------ T1 T1 <------ ... ... <----- T1 <------ T1 T1 <------ ...
/ / / / / /
|_ |_ |_ |_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7 1 2 3 4 5 6 7
Figure 3 Figure 3
In Figure 3, frame 6 is a layer refresh point for temporal layer T1; In Figure 3, frame 6 is a layer refresh point for temporal layer T1;
a decoder which had previously only been decoding temporal layer T0 a decoder that had previously only been decoding temporal layer T0
would be able to decode layer T1 starting at frame 6. would be able to decode layer T1 starting at frame 6.
An illustration of an inherently temporally nested stream is shown An inherently temporally nested stream is shown below. The "<--"
below. <-- indicates a coding dependency. indicates a coding dependency.
T1 T1 T1 T1 T1 T1
/ / / / / /
|_ |_ |_ |_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7 1 2 3 4 5 6 7
Figure 4 Figure 4
In Figure 4, the stream is temporally nested in its ordinary In Figure 4, the stream is temporally nested in its ordinary
structure; a decoder receiving layer T0 can begin decoding layer T1 structure; a decoder receiving layer T0 can begin decoding layer T1
at any point. at any point.
A "Layer Index" is a numeric label for a specific spatial and A "layer index" is a numeric label for a specific spatial and
temporal layer of a scalable stream. It consists of the pair of a temporal layer of a scalable stream. It consists of both a "temporal
"temporal ID" identifying the temporal layer, and a "layer ID" ID" identifying the temporal layer and a "layer ID" identifying the
identifying the spatial or quality layer. The details of how layers spatial or quality layer. The details of how layers of a scalable
of a scalable stream are labeled are codec-specific. Details for stream are labeled are codec specific. Details for several codecs
several codecs are defined in Section 4. are defined in Section 4.
3. Layer Refresh Request 3. Layer Refresh Request
A layer refresh frame can be requested by sending a Layer Refresh A layer refresh frame can be requested by sending a Layer Refresh
Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] Request (LRR), which is an RTCP [RFC3550] payload-specific feedback
payload-specific feedback message [RFC4585] asking the encoder to message [RFC4585] asking the encoder to encode a frame that makes it
encode a frame which makes it possible to upgrade to a higher layer. possible to upgrade to a higher layer. The LRR contains one or two
The LRR contains one or two tuples, indicating the temporal and tuples, indicating the temporal and spatial layer the decoder wants
spatial layer the decoder wants to upgrade to, and (optionally) the to upgrade to and (optionally) the currently highest temporal and
currently highest temporal and spatial layer the decoder can decode. spatial layer the decoder can decode.
The specific format of the tuples, and the mechanism by which a The specific format of the tuples, and the mechanism by which a
receiver recognizes a refresh frame, is codec-dependent. Usage for receiver recognizes a refresh frame, is codec dependent. Usage for
several codecs is discussed in Section 4. several codecs is discussed in Section 4.
LRR follows the model of the Full Intra Request (FIR) [RFC5104] An LRR follows the FIR model (Section 3.5.1 of [RFC5104]) for its
(Section 3.5.1) for its retransmission, reliability, and use in retransmission, reliability, and use in multipoint conferences.
multipoint conferences.
The LRR message is identified by RTCP packet type value PT=PSFB and The LRR message is identified by RTCP packet type value PT=PSFB and
FMT=TBD. The FCI field MUST contain one or more LRR entries. Each FMT=10. The Feedback Control Information (FCI) field MUST contain
entry applies to a different media sender, identified by its SSRC. one or more LRR entries. Each entry applies to a different media
sender, identified by its Synchronization Source (SSRC).
[NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned
payload-specific feedback number.]
3.1. Message Format 3.1. Message Format
The Feedback Control Information (FCI) for the Layer Refresh Request The FCI for the Layer Refresh Request consists of one or more FCI
consists of one or more FCI entries, the content of which is depicted entries, the content of which is depicted in Figure 5. The length of
in Figure 5. The length of the LRR feedback message MUST be set to the LRR feedback message MUST be set to 2+3*N 32-bit words, where N
2+3*N 32-bit words, where N is the number of FCI entries. is the number of FCI entries.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |C| Payload Type| Reserved | | Seq nr. |C| Payload Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TTID| TLID | RES | CTID| CLID | | RES | TTID| TLID | RES | CTID| CLID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 5
SSRC (32 bits) The SSRC value of the media sender that is requested Synchronization Source (SSRC) (32 bits):
to send a layer refresh point. The SSRC value of the media sender that is requested to send a
layer refresh point.
Seq nr. (8 bits) Command sequence number. The sequence number space Seq nr. (8 bits):
is unique for each pairing of the SSRC of command source and the The command sequence number. The sequence number space is unique
SSRC of the command target. The sequence number SHALL be for each pairing of the SSRC of command source and the SSRC of the
increased by 1 for each new command (modulo 256, so the value command target. The sequence number SHALL be increased by 1 for
after 255 is 0). A repetition SHALL NOT increase the sequence each new command (modulo 256, so the value after 255 is 0). A
number. The initial value is arbitrary. repetition SHALL NOT increase the sequence number. The initial
value is arbitrary.
C (1 bit) A flag bit indicating whether the "Current Temporal Layer C (1 bit):
ID (CTID)" and "Current Layer ID (CLID)" fields are present in the A flag bit indicating whether the Current Temporal Layer ID (CTID)
FCI. If this bit is 0, the sender of the LRR message is and Current Layer ID (CLID) fields are present in the FCI. If
requesting refresh of all layers up to and including the target this bit is 0, the sender of the LRR message is requesting refresh
layer. of all layers up to and including the target layer.
Payload Type (7 bits) The RTP payload type for which the LRR is Payload Type (7 bits):
being requested. This gives the context in which the target layer The RTP payload type for which the LRR is being requested. This
index is to be interpreted. gives the context in which the target layer index is to be
interpreted.
Reserved (RES) (three separate fields, 16 bits / 5 bits / 5 bits) Reserved (RES) (three separate fields of 16 bits / 5 bits / 5
bits):
All bits SHALL be set to 0 by the sender and SHALL be ignored on All bits SHALL be set to 0 by the sender and SHALL be ignored on
reception. reception.
Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the Target Temporal Layer ID (TTID) (3 bits):
target layer for which the receiver wishes a refresh point. The temporal ID of the target layer for which the receiver wishes
a refresh point.
Target Layer ID (TLID) (8 bits) The layer ID of the target spatial Target Layer ID (TLID) (8 bits):
or quality layer for which the receiver wishes a refresh point. The layer ID of the target spatial or quality layer for which the
Its format is dependent on the payload type field. receiver wishes a refresh point. Its format is dependent on the
payload type field.
Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the Current Temporal Layer ID (CTID) (3 bits):
current temporal layer being decoded by the receiver. This If C is 1, the ID of the current temporal layer being decoded by
message is not requesting refresh of layers at or below this the receiver. This message is not requesting refresh of layers at
layer. If C is 0, this field SHALL be set to 0 by the sender and or below this layer. If C is 0, this field SHALL be set to 0 by
SHALL be ignored on reception. the sender and SHALL be ignored on reception.
Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the Current Layer ID (CLID) (8 bits):
current spatial or quality layer being decoded by the receiver. If C is 1, the layer ID of the current spatial or quality layer
This message is not requesting refresh of layers at or below this being decoded by the receiver. This message is not requesting
layer. If C is 0, this field SHALL be set to 0 by the sender and refresh of layers at or below this layer. If C is 0, this field
SHALL be ignored on reception. SHALL be set to 0 by the sender and SHALL be ignored on reception.
When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be
less than CLID; at least one of TTID or TLID MUST be greater than less than CLID; at least one of either TTID or TLID MUST be greater
CTID or CLID respectively. That is to say, the target layer index than CTID or CLID, respectively. That is to say, the target layer
<TTID, TLID> MUST be a layer upgrade from the current layer index index <TTID, TLID> MUST be a layer upgrade from the current layer
<CTID, CLID>. A sender MAY request an upgrade in both temporal and index <CTID, CLID>. A sender MAY request an upgrade in both temporal
spatial/quality layers simultaneously. and spatial/quality layers simultaneously.
A receiver receiving an LRR feedback packet which does not satisfy A receiver receiving an LRR feedback packet that does not satisfy the
the requirements of the previous paragraph, i.e. one where the C bit requirements of the previous paragraph, i.e., one where the C bit is
is present but TTID is less than CTID or TLID is less than CLID, MUST present but the TTID is less than the CTID or the TLID is less than
discard the request. the CLID, MUST discard the request.
Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by
design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. design, the TID and LID fields in [RFC9626].
3.2. Semantics 3.2. Semantics
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field Section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source" indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders to is not used and SHALL be set to 0. The SSRCs of the media senders to
which the LRR command applies are in the corresponding FCI entries. which the LRR command applies are in the corresponding FCI entries.
A LRR message MAY contain requests to multiple media senders, using An LRR message MAY contain requests to multiple media senders, using
one FCI entry per target media sender. one FCI entry per target media sender.
Upon reception of LRR, the encoder MUST send a decoder refresh point Upon reception of an LRR, the encoder MUST send a decoder refresh
(see Section 2.1) as soon as possible. point (see Section 2.1) as soon as possible.
The sender MUST respect bandwidth limits provided by the application The sender MUST respect bandwidth limits provided by the application
of congestion control, as described in Section 5 of [RFC5104]. As of congestion control, as described in Section 5 of [RFC5104]. As
layer refresh points will often be larger than non-refreshing frames, layer refresh points will often be larger than non-refreshing frames,
this may restrict a sender's ability to send a layer refresh point this may restrict a sender's ability to send a layer refresh point
quickly. quickly.
LRR MUST NOT be sent as a reaction to picture losses due to packet An LRR MUST NOT be sent as a reaction to picture losses due to packet
loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead. loss or corruption; it is RECOMMENDED to use a PLI (Picture Loss
LRR SHOULD be used only in situations where there is an explicit Indication) [RFC4585] instead. An LRR SHOULD be used only in
change in decoders' behavior, for example when a receiver will start situations where there is an explicit change in a decoders' behavior:
decoding a layer which it previously had been discarding. for example, when a receiver will start decoding a layer that it
previously had been discarding.
4. Usage with specific codecs 4. Usage with Specific Codecs
In order for LRR to be used with a scalable codec, the format of the In order for an LRR to be used with a scalable codec, the format of
temporal and layer ID fields (for both the target and current layer the temporal and layer ID fields (for both the target and current
indices) needs to be specified for that codec's RTP packetization. layer indices) needs to be specified for that codec's RTP
New RTP packetization specifications for scalable codecs SHOULD packetization. New RTP packetization specifications for scalable
define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], codecs SHOULD define how this is done. (The VP9 payload [RFC9628],
for instance, has done so.) If the payload also specifies how it is for instance, has done so.) If the payload also specifies how it is
used with the Frame Marking RTP Header Extension used with the Frame Marking RTP Header Extension [RFC9626], the
[I-D.ietf-avtext-framemarking], the syntax MUST be defined in the syntax MUST be defined in the same manner as the TID and LID fields
same manner as the TID and LID fields in that header. in that header.
4.1. H264 SVC 4.1. H264 SVC
H.264 SVC [RFC6190] defines temporal, dependency (spatial), and H.264 SVC [RFC6190] defines temporal, dependency (spatial), and
quality scalability modes. quality scalability modes.
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |R| DID | QID | | RES | TID |R| DID | QID |
+---------------+---------------+ +---------------+---------------+
Figure 6 Figure 6
Figure 6 shows the format of the layer index fields for H.264 SVC Figure 6 shows the format of the layer index fields for H.264 SVC
streams. The "R" and "RES" fields MUST be set to 0 on transmission streams. The "R" and "RES" fields MUST be set to 0 on transmission
and ignored on reception. See [RFC6190] Section 1.1.3 for details on and ignored on reception. See Section 1.1.3 of [RFC6190] for details
the DID, QID, and TID fields. on the dependency_id (DID), quality_id (QID), and temporal_id (TID)
fields.
A dependency or quality layer refresh of a given layer in H.264 SVC A dependency or quality layer refresh of a given layer in H.264 SVC
can be identified by the "I" bit (idr_flag) in the extended NAL unit can be identified by the "I" bit (idr_flag) in the extended Network
header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded Abstraction Layer (NAL) unit header, present in NAL unit types 14
scalable slice). Layer refresh of the base layer can also be (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of
identified by its NAL unit type of its coded slices, which is "5" the base layer can also be identified by its NAL unit type of its
rather than "1". A dependency or quality layer refresh is complete coded slices, which is "5" rather than "1". A dependency or quality
once this bit has been seen on all the appropriate layers (in layer refresh is complete once this bit has been seen on all the
decoding order) above the current layer index (if any, or beginning appropriate layers (in decoding order) above the current layer index
from the base layer if not) through the target layer index. (if any, or beginning from the base layer if not) through the target
layer index.
Note that as the "I" bit in a PACSI header is set if the Note that as the "I" bit in a Payload Content Scalability Information
corresponding bit is set in any of the aggregated NAL units it (PACSI) header is set if the corresponding bit is set in any of the
describes; thus, it is not sufficient to identify layer refresh when aggregated NAL units it describes; thus, it is not sufficient to
NAL units of multiple dependency or quality layers are aggregated. identify layer refresh when NAL units of multiple dependency or
quality layers are aggregated.
In H.264 SVC, temporal layer refresh information can be determined In H.264 SVC, temporal layer refresh information can be determined
from various Supplemental Encoding Information (SEI) messages in the from various Supplemental Encoding Information (SEI) messages in the
bitstream. bitstream.
Whether an H.264 SVC stream is scalably nested can be determined from Whether an H.264 SVC stream is scalably nested can be determined from
the Scalability Information SEI message's temporal_id_nesting flag. the Scalability Information SEI message's temporal_id_nesting flag.
If this flag is set in a stream's currently applicable Scalability If this flag is set in a stream's currently applicable Scalability
Information SEI, receivers SHOULD NOT send temporal LRR messages for Information SEI, receivers SHOULD NOT send temporal LRR messages for
that stream, as every frame is implicitly a temporal layer refresh that stream, as every frame is implicitly a temporal layer refresh
point. (The Scalability Information SEI message may also be point. (The Scalability Information SEI message may also be
available in the signaling negotiation of H.264 SVC, as the sprop- available in the signaling negotiation of H.264 SVC as the sprop-
scalability-info parameter.) scalability-info parameter.)
If a stream's temporal_id_nesting flag is not set, the Temporal Level If a stream's temporal_id_nesting flag is not set, the Temporal Level
Switching Point SEI message identifies temporal layer switching Switching Point SEI message identifies temporal layer switching
points. A temporal layer refresh is satisfied when this SEI message points. A temporal layer refresh is satisfied when this SEI message
is present in a frame with the target layer index, if the message's is present in a frame with the target layer index, if the message's
delta_frame_num refers to a frame with the requested current layer delta_frame_num refers to a frame with the requested current layer
index. (Alternately, temporal layer refresh can also be satisfied by index. (Alternately, temporal layer refresh can also be satisfied by
a complete state refresh, such as an IDR.) Senders which support a complete state refresh, such as an Instantaneous Decoding Refresh
receiving LRR for non-temporally-nested streams MUST insert Temporal (IDR).) Senders that support receiving an LRR for streams that are
Level Switching Point SEI messages as appropriate. not temporally nested MUST insert Temporal Level Switching Point SEI
messages as appropriate.
4.2. VP8 4.2. VP8
The VP8 RTP payload format [RFC7741] defines temporal scalability The VP8 RTP payload format [RFC7741] defines temporal scalability
modes. It does not support spatial scalability. modes. It does not support spatial scalability.
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID | RES | | RES | TID | RES |
+---------------+---------------+ +---------------+---------------+
Figure 7 Figure 7
Figure 7 shows the format of the layer index field for VP8 streams. Figure 7 shows the format of the layer index field for VP8 streams.
The "RES" fields MUST be set to 0 on transmission and be ignored on The "RES" fields MUST be set to 0 on transmission and be ignored on
reception. See [RFC7741] Section 4.2 for details on the TID field. reception. See Section 4.2 of [RFC7741] for details on the TID
field.
A VP8 layer refresh point can be identified by the presence of the A VP8 layer refresh point can be identified by the presence of the
"Y" bit in the VP8 payload header. When this bit is set, this and "Y" bit in the VP8 payload header. When this bit is set, this and
all subsequent frames depend only on the current base temporal layer. all subsequent frames depend only on the current base temporal layer.
On receipt of an LRR for a VP8 stream, a sender that supports LRRs
On receipt of an LRR for a VP8 stream, A sender which supports LRR
MUST encode the stream so it can set the Y bit in a packet whose MUST encode the stream so it can set the Y bit in a packet whose
temporal layer is at or below the target layer index. temporal layer is at or below the target layer index.
Note that in VP8, not every layer switch point can be identified by Note that in VP8, not every layer switch point can be identified by
the Y bit, since the Y bit implies layer switch of all layers, not the Y bit since the Y bit implies layer switch of all layers, not
just the layer in which it is sent. Thus the use of LRR with VP8 can just the layer in which it is sent. Thus, the use of an LRR with VP8
result in some inefficiency in transmision. However, this is not can result in some inefficiency in transmission. However, this is
expected to be a major issue for temporal structures in normal use. not expected to be a major issue for temporal structures in normal
use.
4.3. H265 4.3. H265
The initial version of the H.265 payload format [RFC7798] defines The initial version of the H.265 payload format [RFC7798] defines
temporal scalability, with protocol elements reserved for spatial or temporal scalability, with protocol elements reserved for spatial or
other scalability modes (which are expected to be defined in a future other scalability modes (which are expected to be defined in a future
version of the specification). version of the specification).
+---------------+---------------+ +---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |RES| LayerId | | RES | TID |RES| LayerId |
+---------------+---------------+ +---------------+---------------+
Figure 8 Figure 8
Figure 8 shows the format of the layer index field for H.265 streams. Figure 8 shows the format of the layer index field for H.265 streams.
The "RES" fields MUST be set to 0 on transmission and ignored on The "RES" fields MUST be set to 0 on transmission and ignored on
reception. See [RFC7798] Section 1.1.4 for details on the LayerId reception. See Section 1.1.4 of [RFC7798] for details on the LayerId
and TID fields. and TID fields.
H.265 streams signal whether they are temporally nested, using the H.265 streams signal whether they are temporally nested by using the
vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and vps_temporal_id_nesting_flag in the Video Parameter Set (VPS) and the
the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If
If this flag is set in a stream's currently applicable VPS or SPS, this flag is set in a stream's currently applicable VPS or SPS,
receivers SHOULD NOT send temporal LRR messages for that stream, as receivers SHOULD NOT send temporal LRR messages for that stream, as
every frame is implicitly a temporal layer refresh point. every frame is implicitly a temporal layer refresh point.
If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit
types 2 to 5 inclusively identify temporal layer switching points. A types 2 to 5 inclusively identify temporal layer switching points. A
layer refresh to any higher target temporal layer is satisfied when a layer refresh to any higher target temporal layer is satisfied when a
NAL unit type of 4 or 5 with TID equal to 1 more than current TID is NAL unit type of 4 or 5 with TID equal to 1 more than current TID is
seen. Alternatively, layer refresh to a target temporal layer can be seen. Alternatively, layer refresh to a target temporal layer can be
incrementally satisfied with NAL unit type of 2 or 3. In this case, incrementally satisfied with a NAL unit type of 2 or 3. In this
given current TID = TO and target TID = TN, layer refresh to TN is case, given current TID = TO and target TID = TN, layer refresh to TN
satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID is satisfied when a NAL unit type of 2 or 3 is seen for TID = T1,
= T2, all the way up to TID = TN. During this incremental process, then TID = T2, all the way up to TID = TN. During this incremental
layer refresh to TN can be completely satisfied as soon as a NAL unit process, layer refresh to TN can be completely satisfied as soon as a
type of 2 or 3 is seen. NAL unit type of 2 or 3 is seen.
Of course, temporal layer refresh can also be satisfied whenever any Of course, temporal layer refresh can also be satisfied whenever any
Intra Random Access Point (IRAP) NAL unit type (with values 16-23, Intra-Random Access Point (IRAP) NAL unit type (with values 16-23,
inclusively) is seen. An IRAP picture is similar to an IDR picture inclusively) is seen. An IRAP picture is similar to an IDR picture
in H.264 (NAL unit type of 5 in H.264) where decoding of the picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture
can start without any older pictures. can start without any older pictures.
In the (future) H.265 payloads that support spatial scalability, a In the (future) H.265 payloads that support spatial scalability, a
spatial layer refresh of a specific layer can be identified by NAL spatial layer refresh of a specific layer can be identified by NAL
units with the requested layer ID and NAL unit types between 16 and units with the requested layer ID and NAL unit types between 16 and
21 inclusive. A dependency or quality layer refresh is complete once 21, inclusive. A dependency or quality layer refresh is complete
NAL units of this type have been seen on all the appropriate layers once NAL units of this type have been seen on all the appropriate
(in decoding order) above the current layer index (if any, or layers (in decoding order) above the current layer index (if any, or
beginning from the base layer if not) through the target layer index. beginning from the base layer if not) through the target layer index.
5. Usage with different scalability transmission mechanisms 5. Usage with Different Scalability Transmission Mechanisms
Several different mechanisms are defined for how scalable streams can Several different mechanisms are defined for how scalable streams can
be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 be transmitted in RTP. The RTP Taxonomy (Section 3.7 of [RFC7656])
defines three mechanisms: Single RTP Stream on a Single Media defines three mechanisms: Single RTP stream on a Single media
Transport (SRST), Multiple RTP Streams on a Single Media Transport Transport (SRST), Multiple RTP streams on a Single media Transport
(MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). (MRST), and Multiple RTP streams on Multiple media Transports (MRMT).
The LRR message is applicable to all these mechanisms. For MRST and The LRR message is applicable to all these mechanisms. For MRST and
MRMT mechanisms, the "media source" field of the LRR FCI is set to MRMT mechanisms, the "media source" field of the LRR FCI is set to
the SSRC of the RTP stream containing the layer indicated by the the SSRC of the RTP stream containing the layer indicated by the
Current Layer Index (if "C" is 1), or the stream containing the base Current Layer Index (if "C" is 1) or the stream containing the base
encoded stream (if "C" is 0). For MRMT, it is sent on the RTP encoded stream (if "C" is 0). For MRMT, it is sent on the RTP
session on which this stream is sent. On receipt, the sender MUST session on which this stream is sent. On receipt, the sender MUST
refresh all the layers requested in the stream, simultaneously in refresh all the layers requested in the stream, simultaneously in
decode order. decode order.
6. SDP Definitions 6. SDP Definitions
Section 7 of [RFC5104] defines SDP procedures for indicating and Section 7 of [RFC5104] defines Session Description Protocol (SDP)
negotiating support for codec control messages (CCM) in SDP. This procedures for indicating and negotiating support for Codec Control
document extends this with a new codec control command, "lrr", which Messages (CCM) in SDP. This document extends this with a new codec
indicates support of the Layer Refresh Request (LRR). control command, "lrr", which indicates support of the LRR.
Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
showing this grammar extension, extending the grammar defined in showing this grammar extension, extending the grammar defined in
[RFC5104]. [RFC5104].
rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request
Figure 9: Syntax of the "lrr" ccm Figure 9: Syntax of the "lrr" CCM
The Offer-Answer considerations defined in [RFC5104] Section 7.2 The Offer-Answer considerations defined in Section 7.2 of [RFC5104]
apply. apply.
7. Security Considerations 7. Security Considerations
All the security considerations of FIR feedback packets [RFC5104] All the security considerations of FIR feedback packets [RFC5104]
apply to LRR feedback packets as well. Additionally, media senders apply to LRR feedback packets as well. Additionally, media senders
receiving LRR feedback packets MUST validate that the payload types receiving LRR feedback packets MUST validate that the payload types
and layer indices they are receiving are valid for the stream they and layer indices they are receiving are valid for the stream they
are currently sending, and discard the requests if not. are currently sending, and discard the requests if not.
8. IANA Considerations 8. IANA Considerations
This document defines a new entry to the "Codec Control Messages" This document defines a new entry to the "Codec Control Messages"
subregistry of the "Session Description Protocol (SDP) Parameters" subregistry of the "Session Description Protocol (SDP) Parameters"
registry, according to the following data: registry, according to the following data:
Value name: lrr Value Name: lrr
Long Name: Layer Refresh Request Command
Long name: Layer Refresh Request Command
Usable with: ccm Usable with: ccm
Mux: IDENTICAL-PER-PT Mux: IDENTICAL-PER-PT
Reference: RFC 9627
Reference: RFC XXXX
This document also defines a new entry to the "FMT Values for PSFB This document also defines a new entry to the "FMT Values for PSFB
Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) Payload Types" subregistry of the "Real-Time Transport Protocol (RTP)
Parameters" registry, according to the following data: Parameters" registry, according to the following data:
Name: LRR Name: LRR
Long Name: Layer Refresh Request Command Long Name: Layer Refresh Request Command
Value: 10
Value: TBD Reference: RFC 9627
Reference: RFC XXXX
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-avtext-framemarking]
Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking
RTP Header Extension", draft-ietf-avtext-framemarking-05
(work in progress), July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
"RTP Payload Format for Scalable Video Coding", RFC 6190, Eleftheriadis, "RTP Payload Format for Scalable Video
DOI 10.17487/RFC6190, May 2011, Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>. <https://www.rfc-editor.org/info/rfc6190>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741, Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016, DOI 10.17487/RFC7741, March 2016,
<http://www.rfc-editor.org/info/rfc7741>. <https://www.rfc-editor.org/info/rfc7741>.
[RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. [RFC7798] Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M.
Hannuksela, "RTP Payload Format for High Efficiency Video M. Hannuksela, "RTP Payload Format for High Efficiency
Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798,
2016, <http://www.rfc-editor.org/info/rfc7798>. March 2016, <https://www.rfc-editor.org/info/rfc7798>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-payload-vp9] [RFC9626] Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame
Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Marking RTP Header Extension", RFC 9621,
Hong, "RTP Payload Format for VP9 Video", draft-ietf- DOI 10.17487/RFC9621, August 2024,
payload-vp9-04 (work in progress), July 2017. <https://www.rfc-editor.org/info/rfc9626>.
9.2. Informative References
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund,
"Using Codec Control Messages in the RTP Audio-Visual "Using Codec Control Messages in the RTP Audio-Visual
Profile with Feedback with Layered Codecs", RFC 8082, Profile with Feedback with Layered Codecs", RFC 8082,
DOI 10.17487/RFC8082, March 2017, DOI 10.17487/RFC8082, March 2017,
<http://www.rfc-editor.org/info/rfc8082>. <https://www.rfc-editor.org/info/rfc8082>.
[RFC9628] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", RFC 9628, DOI 10.17487/RFC9628, August 2024,
<https://www.rfc-editor.org/info/rfc9628>.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. 8x8, Inc. / Jitsi
433 Hackensack Avenue Jersey City, NJ 07302
Seventh Floor United States of America
Hackensack, NJ 07601 Email: jonathan.lennox@8x8.com
US
Email: jonathan@vidyo.com
Danny Hong Danny Hong
Vidyo, Inc. Vidyo, Inc.
433 Hackensack Avenue 433 Hackensack Avenue
Seventh Floor Seventh Floor
Hackensack, NJ 07601 Hackensack, NJ 07601
US United States of America
Email: danny@vidyo.com Email: danny@vidyo.com
Justin Uberti Justin Uberti
Google, Inc. Google, Inc.
747 6th Street South 747 6th Street South
Kirkland, WA 98033 Kirkland, WA 98033
USA United States of America
Email: justin@uberti.name Email: justin@uberti.name
Stefan Holmer Stefan Holmer
Google, Inc. Google, Inc.
Kungsbron 2 Kungsbron 2
Stockholm 111 22 SE-111 22 Stockholm
Sweden Sweden
Email: holmer@google.com Email: holmer@google.com
Magnus Flodman Magnus Flodman
Google, Inc. Google, Inc.
Kungsbron 2 Kungsbron 2
Stockholm 111 22 SE-111 22 Stockholm
Sweden Sweden
Email: mflodman@google.com Email: mflodman@google.com
 End of changes. 108 change blocks. 
278 lines changed or deleted 277 lines changed or added

This html diff was produced by rfcdiff 1.48.