draft-ietf-avtext-framemarking-09.txt   draft-ietf-avtext-framemarking-10.txt 
Network Working Group M. Zanaty Network Working Group M. Zanaty
Internet-Draft E. Berger Internet-Draft E. Berger
Intended status: Standards Track S. Nandakumar Intended status: Standards Track S. Nandakumar
Expires: September 29, 2019 Cisco Systems Expires: May 24, 2020 Cisco Systems
March 28, 2019 November 21, 2019
Frame Marking RTP Header Extension Frame Marking RTP Header Extension
draft-ietf-avtext-framemarking-09 draft-ietf-avtext-framemarking-10
Abstract Abstract
This document describes a Frame Marking RTP header extension used to This document describes a Frame Marking RTP header extension used to
convey information about video frames that is critical for error convey information about video frames that is critical for error
recovery and packet forwarding in RTP middleboxes or network nodes. recovery and packet forwarding in RTP middleboxes or network nodes.
It is most useful when media is encrypted, and essential when the It is most useful when media is encrypted, and essential when the
middlebox or node has no access to the media decryption keys. It is middlebox or node has no access to the media decryption keys. It is
also useful for codec-agnostic processing of encrypted or unencrypted also useful for codec-agnostic processing of encrypted or unencrypted
media, while it also supports extensions for codec-specific media, while it also supports extensions for codec-specific
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2019. This Internet-Draft will expire on May 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words for Normative Requirements . . . . . . . . . . . . 4 2. Key Words for Normative Requirements . . . . . . . . . . . . 4
3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4 3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4
3.1. Short Extension for Non-Scalable Streams . . . . . . . . 4 3.1. Short Extension for Non-Scalable Streams . . . . . . . . 4
3.2. Long Extension for Scalable Streams . . . . . . . . . . . 5 3.2. Long Extension for Scalable Streams . . . . . . . . . . . 5
3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 7 3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 7
3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 7 3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 7
3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 7 3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 8
3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 8 3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 8
3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 8 3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 8
3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 8 3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 8
3.3. Signaling Information . . . . . . . . . . . . . . . . . . 8 3.3. Signaling Information . . . . . . . . . . . . . . . . . . 9
3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 9 3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 9
3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9 3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 9
3.4.2. Scalability Structures . . . . . . . . . . . . . . . 9 3.4.2. Scalability Structures . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
skipping to change at page 5, line 26 skipping to change at page 5, line 26
o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame; o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame;
otherwise MUST be 0. SHOULD match the RTP header marker bit in otherwise MUST be 0. SHOULD match the RTP header marker bit in
payload formats with such semantics for marking end of frame. payload formats with such semantics for marking end of frame.
o I: Independent Frame (1 bit) - MUST be 1 for frames that can be o I: Independent Frame (1 bit) - MUST be 1 for frames that can be
decoded independent of temporally prior frames, e.g. intra-frame, decoded independent of temporally prior frames, e.g. intra-frame,
VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP
[RFC7798]; otherwise MUST be 0. [RFC7798]; otherwise MUST be 0.
o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender
knows can be discarded, and still provide a decodable media knows can be discarded, and still provide a decodable media
stream; otherwise MUST be 0. stream; otherwise MUST be 0.
o The remaining (4 bits) - are reserved for future use for non- o The remaining (4 bits) - are reserved/fixed values and not used
scalable streams; they MUST be set to 0 upon transmission and for non-scalable streams; they MUST be set to 0 upon transmission
ignored upon reception. and ignored upon reception.
3.2. Long Extension for Scalable Streams 3.2. Long Extension for Scalable Streams
The following RTP header extension is RECOMMENDED for scalable The following RTP header extension is RECOMMENDED for scalable
streams. It MAY also be used for non-scalable streams, in which case streams. It MAY also be used for non-scalable streams, in which case
TID, LID and TL0PICIDX MUST be 0 or omitted. The ID is assigned per TID, LID and TL0PICIDX MUST be 0 or omitted. The ID is assigned per
[RFC8285], and the length is encoded as L=2 which indicates 3 octets [RFC8285], and the length is encoded as L=2 which indicates 3 octets
of data when nothing is omitted, or L=1 for 2 octets when TL0PICIDX of data when nothing is omitted, or L=1 for 2 octets when TL0PICIDX
is omitted, or L=0 for 1 octet when both LID and TL0PICIDX are is omitted, or L=0 for 1 octet when both LID and TL0PICIDX are
omitted. omitted.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
o I: Independent Frame (1 bit) - MUST be 1 for frames that can be o I: Independent Frame (1 bit) - MUST be 1 for frames that can be
decoded independent of temporally prior frames, e.g. intra-frame, decoded independent of temporally prior frames, e.g. intra-frame,
VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP
[RFC7798]; otherwise MUST be 0. Note that this bit only signals [RFC7798]; otherwise MUST be 0. Note that this bit only signals
temporal independence, so it can be 1 in spatial or quality temporal independence, so it can be 1 in spatial or quality
enhancement layers that depend on temporally co-located layers but enhancement layers that depend on temporally co-located layers but
not temporally prior frames. not temporally prior frames.
o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender o D: Discardable Frame (1 bit) - MUST be 1 for frames the sender
knows can be discarded, and still provide a decodable media knows can be discarded, and still provide a decodable media
stream; otherwise MUST be 0. stream; otherwise MUST be 0.
o B: Base Layer Sync (1 bit) - MUST be 1 if the sender knows this o B: Base Layer Sync (1 bit) - When TID is not 0, this MUST be 1 if
frame only depends on the base temporal layer; otherwise MUST be the sender knows this frame only depends on the base temporal
0. If no scalability is used, this MUST be 0. layer; otherwise MUST be 0. When TID is 0 or if no scalability is
used, this MUST be 0.
o TID: Temporal ID (3 bits) - The base temporal layer starts with 0, o TID: Temporal ID (3 bits) - The base temporal layer starts with 0,
and increases with 1 for each higher temporal layer/sub-layer. If and increases with 1 for each higher temporal layer/sub-layer. If
no scalability is used, this MUST be 0. no scalability is used, this MUST be 0. It is implicitly 0 in the
short extension format.
o LID: Layer ID (8 bits) - Identifies the spatial and quality layer o LID: Layer ID (8 bits) - Identifies the spatial and quality layer
encoded, starting with 0 and increasing with higher fidelity. If encoded, starting with 0 and increasing with higher fidelity. If
no scalability is used, this MUST be 0 or omitted to reduce no scalability is used, this MUST be 0 or omitted to reduce
length. When omitted, TL0PICIDX MUST also be omitted. length. When omitted, TL0PICIDX MUST also be omitted. It is
o TL0PICIDX: Temporal Layer 0 Picture Index (8 bits) - Running index implicitly 0 in the short extension format or when omitted in the
of base temporal layer 0 frames when TID is 0. When TID is not 0, long extension format.
this indicates a dependency on the given index. If no scalability
is used, or the running index is unknown, this MUST be omitted to o TL0PICIDX: Temporal Layer 0 Picture Index (8 bits) - When TID is 0
reduce length. Note that 0 is a valid running index value for and LID is 0, this is a cyclic counter labeling base layer frames.
TL0PICIDX. When TID is not 0 or LID is not 0, this indicates a dependency on
the given index, such that this frame in this layer depends on the
frame with this label in the layer with TID 0 and LID 0. If no
scalability is used, or the cyclic counter is unknown, this MUST
be omitted to reduce length. Note that 0 is a valid index value
for TL0PICIDX.
The layer information contained in TID and LID convey useful aspects The layer information contained in TID and LID convey useful aspects
of the layer structure that can be utilized in selective forwarding. of the layer structure that can be utilized in selective forwarding.
Without further information about the layer structure, these Without further information about the layer structure, these
identifiers can only be used for relative priority of layers. They identifiers can only be used for relative priority of layers. They
convey a layer hierarchy with TID=0 and LID=0 identifying the base convey a layer hierarchy with TID=0 and LID=0 identifying the base
layer. Higher values of TID identify higher temporal layers with layer. Higher values of TID identify higher temporal layers with
higher frame rates. Higher values of LID identify higher spatial higher frame rates. Higher values of LID identify higher spatial
and/or quality layers with higher resolutions and/or bitrates. and/or quality layers with higher resolutions and/or bitrates.
skipping to change at page 7, line 27 skipping to change at page 7, line 34
items that convey full layer structure information, it may be items that convey full layer structure information, it may be
possible to map these TIDs and LIDs to specific frame rates, possible to map these TIDs and LIDs to specific frame rates,
resolutions and bitrates. Such additional layer information may be resolutions and bitrates. Such additional layer information may be
useful for forwarding decisions in the RTP switch, but is beyond the useful for forwarding decisions in the RTP switch, but is beyond the
scope of this memo. The relative layer information is still useful scope of this memo. The relative layer information is still useful
for many selective forwarding decisions even without such additional for many selective forwarding decisions even without such additional
layer information. layer information.
3.2.1. Layer ID Mappings for Scalable Streams 3.2.1. Layer ID Mappings for Scalable Streams
This section maps the specific Layer ID information contained in
specific scalable codecs to the generic LID and TID fields.
Note that non-scalable streams have no Layer ID information and thus
no mappings.
3.2.1.1. H265 LID Mapping 3.2.1.1. H265 LID Mapping
The following shows the H265 [RFC7798] LayerID (6 bits) and TID (3 The following shows the H265 [RFC7798] LayerID (6 bits) and TID (3
bits) from the NAL unit header mapped to the generic LID and TID bits) from the NAL unit header mapped to the generic LID and TID
fields. fields.
The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive), The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive),
otherwise it MUST be 0. otherwise it MUST be 0.
The S and E bits MUST match the corresponding bits in PACI:PHES:TSCI The S and E bits MUST match the corresponding bits in PACI:PHES:TSCI
payload structures. payload structures.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=2 | L=2 |S|E|I|D|B| TID |0|0| LayerID | TL0PICIDX | | ID=? | L=2 |S|E|I|D|B| TID |0|0| LayerID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1.2. H264-SVC LID Mapping 3.2.1.2. H264-SVC LID Mapping
The following shows H264-SVC [RFC6190] Layer encoding information (3 The following shows H264-SVC [RFC6190] Layer encoding information (3
bits for spatial/dependency layer, 4 bits for quality layer and 3 bits for spatial/dependency layer, 4 bits for quality layer and 3
bits for temporal layer) mapped to the generic LID and TID fields. bits for temporal layer) mapped to the generic LID and TID fields.
The S, E, I and D bits MUST match the corresponding bits in PACSI The S, E, I and D bits MUST match the corresponding bits in PACSI
payload structures. payload structures.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=2 | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX | | ID=? | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1.3. H264 (AVC) LID Mapping 3.2.1.3. H264 (AVC) LID Mapping
The following shows the header extension for H264 (AVC) [RFC6184] The following shows the header extension for H264 (AVC) [RFC6184]
that contains only temporal layer information. that contains only temporal layer information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | | ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1.4. VP8 LID Mapping 3.2.1.4. VP8 LID Mapping
The following shows the header extension for VP8 [RFC7741] that The following shows the header extension for VP8 [RFC7741] that
contains only temporal layer information. contains only temporal layer information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | | ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1.5. Future Codec LID Mapping 3.2.1.5. Future Codec LID Mapping
The RTP payload format specification for future video codecs SHOULD The RTP payload format specification for future video codecs SHOULD
include a section describing the LID mapping and TID mapping for the include a section describing the LID mapping and TID mapping for the
codec. For example, the LID/TID mapping for the VP9 codec is codec. For example, the LID/TID mapping for the VP9 codec is
described in the VP9 RTP Payload Format [I-D.ietf-payload-vp9]. described in the VP9 RTP Payload Format [I-D.ietf-payload-vp9].
3.3. Signaling Information 3.3. Signaling Information
skipping to change at page 10, line 15 skipping to change at page 10, line 29
4. Security Considerations 4. Security Considerations
In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP
header extensions are authenticated but usually not encrypted. When header extensions are authenticated but usually not encrypted. When
header extensions are used some of the payload type information are header extensions are used some of the payload type information are
exposed and visible to middle boxes. The encrypted media data is not exposed and visible to middle boxes. The encrypted media data is not
exposed, so this is not seen as a high risk exposure. exposed, so this is not seen as a high risk exposure.
5. Acknowledgements 5. Acknowledgements
Many thanks to Bernard Aboba, Jonathan Lennox, and Stephan Wenger for Many thanks to Bernard Aboba, Jonathan Lennox, Stephan Wenger, and
their inputs. Dale Worley for their inputs.
6. IANA Considerations 6. IANA Considerations
This document defines a new extension URI to the RTP Compact This document defines a new extension URI to the RTP Compact
HeaderExtensions sub-registry of the Real-Time Transport Protocol HeaderExtensions sub-registry of the Real-Time Transport Protocol
(RTP) Parameters registry, according to the following data: (RTP) Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo
Description: Frame marking information for video streams Description: Frame marking information for video streams
Contact: mzanaty@cisco.com Contact: mzanaty@cisco.com
skipping to change at page 11, line 31 skipping to change at page 11, line 46
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-07 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
July 2017. July 2017.
[I-D.ietf-payload-vp9] [I-D.ietf-payload-vp9]
Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D.
Hong, "RTP Payload Format for VP9 Video", draft-ietf- Hong, "RTP Payload Format for VP9 Video", draft-ietf-
payload-vp9-06 (work in progress), July 2018. payload-vp9-07 (work in progress), July 2019.
[I-D.ietf-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-09 Conferencing (PERC)", draft-ietf-perc-private-media-
(work in progress), February 2019. framework-12 (work in progress), June 2019.
[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, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
 End of changes. 18 change blocks. 
30 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/