draft-ietf-avtcore-rfc5285-bis-12.txt   draft-ietf-avtcore-rfc5285-bis-13.txt 
AVTCore D. Singer AVTCore D. Singer
Internet-Draft Apple, Inc. Internet-Draft Apple, Inc.
Obsoletes: 5285 (if approved) H. Desineni Obsoletes: 5285 (if approved) H. Desineni
Intended status: Standards Track Qualcomm Intended status: Standards Track Qualcomm
Expires: December 5, 2017 R. Even, Ed. Expires: January 23, 2018 R. Even, Ed.
Huawei Technologies Huawei Technologies
June 3, 2017 July 22, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-12.txt draft-ietf-avtcore-rfc5285-bis-13.txt
Abstract Abstract
This document provides a general mechanism to use the header This document provides a general mechanism to use the header
extension feature of RTP (the Real-Time Transport Protocol). It extension feature of RTP (the Real-Time Transport Protocol). It
provides the option to use a small number of small extensions in each provides the option to use a small number of small extensions in each
RTP packet, where the universe of possible extensions is large and RTP packet, where the universe of possible extensions is large and
registration is de-centralized. The actual extensions in use in a registration is de-centralized. The actual extensions in use in a
session are signaled in the setup information for that session. This session are signaled in the setup information for that session. This
document obsoletes RFC5285. document obsoletes RFC5285.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 5, 2017. This Internet-Draft will expire on January 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (http://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 26 skipping to change at page 2, line 26
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Transmission Considerations . . . . . . . . . . . . . 5 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5
4.1.2. Header Extension Type Considerations . . . . . . . . 6 4.1.2. Header Extension Type Considerations . . . . . . . . 6
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10
6. SDP Signaling for support of mixed one byte and two bytes 6. SDP Signaling for support of mixed one byte and two bytes
header extensions. . . . . . . . . . . . . . . . . . . . . . 12 header extensions. . . . . . . . . . . . . . . . . . . . . . 12
7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13 7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17
10.2. Registration of the SDP extmap Attribute . . . . . . . . 19 10.2. Registration of the SDP extmap Attribute . . . . . . . . 19
10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 20 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 6, line 36 skipping to change at page 6, line 36
greater than 0. If such an extension element is encountered, its greater than 0. If such an extension element is encountered, its
length field MUST be ignored, processing of the entire extension MUST length field MUST be ignored, processing of the entire extension MUST
terminate at that point, and only the extension elements present terminate at that point, and only the extension elements present
prior to the element with ID 0 and len field greater than 0 SHOULD be prior to the element with ID 0 and len field greater than 0 SHOULD be
considered. considered.
There are two variants of the extension: one-byte and two-byte There are two variants of the extension: one-byte and two-byte
headers. Since it is expected that (a) the number of extensions in headers. Since it is expected that (a) the number of extensions in
any given RTP session is small and (b) the extensions themselves are any given RTP session is small and (b) the extensions themselves are
small, the one-byte header form is preferred and MUST be supported by small, the one-byte header form is preferred and MUST be supported by
all receivers. A stream MUST contain only one-byte or two-byte all receivers. A stream MUST contain only one-byte or only two-byte
headers unless it is known that all recipients support mixing, either headers unless it is known that all recipients support mixing, either
by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out- by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
of-band knowledge. Each RTP packet with an RTP header extension of-band knowledge. Each RTP packet with an RTP header extension
following this specification will indicate if it contains one or two following this specification will indicate if it contains one or two
byte header extensions through the use of the "defined by profile" byte header extensions through the use of the "defined by profile"
field. Extension element types that dp not match the header field. Extension element types that do not match the header
extension format, i.e. one- or two-byte, MUST NOT be used in that RTP extension format, i.e. one- or two-byte, MUST NOT be used in that RTP
packet. Transmitters SHOULD NOT use the two-byte form when all packet. Transmitters SHOULD NOT use the two-byte form when all
extensions are small enough for the one-byte header form. extensions are small enough for the one-byte header form.
Transmitters that intend to send the two-byte form SHOULD negotiate Transmitters that intend to send the two-byte form SHOULD negotiate
the use of IDs above 14 if they want to let the Receivers know that the use of IDs above 14 if they want to let the Receivers know that
they intend to use two-byte form, for example if the RTP header they intend to use two-byte form, for example if the RTP header
extension is longer than 16 bytes. A transmitter may be aware that extension is longer than 16 bytes. A transmitter may be aware that
an intermediary may add RTP header extensions in this case, the an intermediary may add RTP header extensions; in this case the
transmitter SHOULD use two-byte form. transmitter SHOULD use two-byte form.
A sequence of extension elements, possibly with padding, forms the A sequence of extension elements, possibly with padding, forms the
header extension defined in the RTP specification. There are as many header extension defined in the RTP specification. There are as many
extension elements as fit into the length as indicated in the RTP extension elements as fit into the length as indicated in the RTP
header extension length. Since this length is signaled in full header extension length. Since this length is signaled in full
32-bit words, padding bytes are used to pad to a 32-bit boundary. 32-bit words, padding bytes are used to pad to a 32-bit boundary.
The entire extension is parsed byte-by-byte to find each extension The entire extension is parsed byte-by-byte to find each extension
element (no alignment is needed), and parsing stops at the earlier of element (no alignment is needed), and parsing stops at the earlier of
the end of the entire header extension, or in one-byte headers only the end of the entire header extension, or in "one-byte headers only"
case, on encountering an identifier with the reserved value of 15. case, on encountering an identifier with the reserved value of 15.
In both forms, padding bytes have the value of 0 (zero). They MAY be In both forms, padding bytes have the value of 0 (zero). They MAY be
placed between extension elements, if desired for alignment, or after placed between extension elements, if desired for alignment, or after
the last extension element, if needed for padding. A padding byte the last extension element, if needed for padding. A padding byte
does not supply the ID of an element, nor the length field. When a does not supply the ID of an element, nor the length field. When a
padding byte is found, it is ignored and the parser moves on to padding byte is found, it is ignored and the parser moves on to
interpreting the next byte. interpreting the next byte.
Note carefully that the one-byte header form allows for data lengths Note carefully that the one-byte header form allows for data lengths
skipping to change at page 7, line 44 skipping to change at page 7, line 44
requiring an update to the fixed header to be conveyed when header requiring an update to the fixed header to be conveyed when header
extensions start or stop being sent. The interactions of the RTP extensions start or stop being sent. The interactions of the RTP
header extension and header compression is explored further in header extension and header compression is explored further in
[RFC2508] and [RFC3095]. [RFC2508] and [RFC3095].
4.2. One-Byte Header 4.2. One-Byte Header
In the one-byte header form of extensions, the 16-bit value required In the one-byte header form of extensions, the 16-bit value required
by the RTP specification for a header extension, labeled in the RTP by the RTP specification for a header extension, labeled in the RTP
specification as "defined by profile", MUST have the fixed bit specification as "defined by profile", MUST have the fixed bit
pattern 0xBEDE (the first version of this specification was written pattern 0xBEDE (the pattern was picked for the trivial reason that
on the feast day of the Venerable Bede). the first version of this specification was written on May 25th the
feast day of the Venerable Bede).
Each extension element MUST starts with a byte containing an ID and a Each extension element MUST start with a byte containing an ID and a
length: length:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| ID | len | | ID | len |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 4-bit ID is the local identifier of this element in the range The 4-bit ID is the local identifier of this element in the range
1-14 inclusive. In the signaling section, this is referred to as the 1-14 inclusive. In the signaling section, this is referred to as the
skipping to change at page 12, line 7 skipping to change at page 12, line 7
specification. specification.
Example: Example:
a=extmap:1 http://example.com/082005/ext.htm#ttime a=extmap:1 http://example.com/082005/ext.htm#ttime
a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short
When SDP signaling is used for the RTP session, it is the presence of When SDP signaling is used for the RTP session, it is the presence of
the 'extmap' attribute(s) that is diagnostic that this style of the 'extmap' attribute(s) that is diagnostic that this style of
header extensions is used, not the magic number indicated above. header extensions is used, not the magic number ("BEDE" or "100")
indicated above.
6. SDP Signaling for support of mixed one byte and two bytes header 6. SDP Signaling for support of mixed one byte and two bytes header
extensions. extensions.
In order to allow for backward interoperability with systems that do In order to allow for backward interoperability with systems that do
not support mixing of one byte and two bytes header extensions this not support mixing of one byte and two bytes header extensions this
document defines the "a=extmap-allow-mixed" Session Description document defines the "a=extmap-allow-mixed" Session Description
Protocol (SDP) [RFC4566] attribute to indicate if the participant is Protocol (SDP) [RFC4566] attribute to indicate if the participant is
capable of supporting this new mode. The attribute takes no value. capable of supporting this new mode. The attribute takes no value.
This attribute can be used at the session or media levels. A This attribute can be used at the session or media levels. A
skipping to change at page 12, line 32 skipping to change at page 12, line 33
for mixed one byte and two bytes extension MUST be negotiated using for mixed one byte and two bytes extension MUST be negotiated using
SDP Offer/Answer [RFC3264]. In the absence of negotiations using SDP SDP Offer/Answer [RFC3264]. In the absence of negotiations using SDP
Offer/Answer, for example when declarative SDP is used, mixed headers Offer/Answer, for example when declarative SDP is used, mixed headers
MUST NOT occur unless the transmitter has some (out of band) MUST NOT occur unless the transmitter has some (out of band)
knowledge that all potential recipients support this mode. knowledge that all potential recipients support this mode.
The formal definition of this attribute is: The formal definition of this attribute is:
Name: extmap-allow-mixed Name: extmap-allow-mixed
Value: Value: none
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Example: Example:
a=extmap-allow-mixed a=extmap-allow-mixed
When doing SDP Offer/Answer [RFC3264] an offering client that wishes When doing SDP Offer/Answer [RFC3264] an offering client that wishes
to use both one and two bytes extensions MUST include the attribute to use both one and two bytes extensions MUST include the attribute
"a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed
" is present in the offer SDP, the answerer that supports this mode " is present in the offer SDP, the answerer that supports this mode
and wishes to use it SHALL include the "a=extmap-allow-mixed " and wishes to use it SHALL include the "a=extmap-allow-mixed "
attribute in the answer. In the cases where the attribute has been attribute in the answer. In the cases where the attribute has been
excluded, both clients SHALL NOT use mixed one bytes and two bytes excluded, both clients SHALL NOT use mixed one bytes and two bytes
extensions in the same RTP stream but MAY use one-byte or two-bytes extensions in the same RTP stream but MAY use one-byte or two-bytes
form exclusively (see section 4.1.2). form exclusively (see section 4.1.2).
When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute
is specified as normal category for the is specified as identical category for the
[I-D.ietf-mmusic-sdp-mux-attributes]. This allows for only a subset [I-D.ietf-mmusic-sdp-mux-attributes]. This allows for only a subset
of the m-lines in the bundle group to offer extmap-allow-mixed. When of the m-lines in the bundle group to offer extmap-allow-mixed. When
an answerer supporting the extmap-allow-mix attribute receives an an answerer supporting the extmap-allow-mix attribute receives an
offer where only some of the m-lines in the bundle group include the offer where only some of the m-lines in the bundle group include the
extmap-allow-mixed attribute, the answerer MUST receive this offer extmap-allow-mixed attribute, the answerer MUST receive this offer
and support mixed one-byte and two-bytes only for those m-lines. and support mixed one-byte and two-bytes only for those m-lines.
Transmitters MUST only send RTP header extensions using mixed on Transmitters MUST only send RTP header extensions using mixed on
those RTP streams originating from those media sources (m=) blocks those RTP streams originating from those media sources (m=) blocks
that includes extmap-allow-mixed, and are RECOMMENDED to support that includes extmap-allow-mixed, and are RECOMMENDED to support
receiving mixed on all RTP streams being received in an RTP session receiving mixed on all RTP streams being received in an RTP session
skipping to change at page 14, line 9 skipping to change at page 14, line 9
to make identifier management easier.) to make identifier management easier.)
If an extension map is offered as "sendrecv", explicitly or If an extension map is offered as "sendrecv", explicitly or
implicitly, and asymmetric behavior is desired, the SDP answer MAY be implicitly, and asymmetric behavior is desired, the SDP answer MAY be
changed to modify or add direction qualifiers for that extension. changed to modify or add direction qualifiers for that extension.
If an extension is marked as "sendonly" and the answerer desires to If an extension is marked as "sendonly" and the answerer desires to
receive it, the extension MUST be marked as "recvonly" in the SDP receive it, the extension MUST be marked as "recvonly" in the SDP
answer. An answerer that has no desire to receive the extension or answer. An answerer that has no desire to receive the extension or
does not understand the extension SHOULD remove it from the SDP does not understand the extension SHOULD remove it from the SDP
answer. answer. An answerer MAY want to respond that he supports the
extension and may use it in the future will mark the extension as
"inactive"
If an extension is marked as "recvonly" and the answerer desires to If an extension is marked as "recvonly" and the answerer desires to
send it, the extension MUST be marked as "sendonly" in the SDP send it, the extension MUST be marked as "sendonly" in the SDP
answer. An answerer that has no desire to, or is unable to, send the answer. An answerer that has no desire to, or is unable to, send the
extension SHOULD remove it from the SDP answer. extension SHOULD remove it from the SDP answer. An answerer MAY want
to respond that he support this extension and may send in the future
or will be able to receive by marking the extension as "inactive"
Local identifiers in the valid range inclusive in an offer or answer Local identifiers in the valid range inclusive in an offer or answer
must not be used more than once per media section (including the must not be used more than once per media section (including the
session-level section). A session update MAY change the direction session-level section). The local dentifiers MUST be unique in an
RTP session and the same identifier MUST be used for the same offered
extension in the answer. A session update MAY change the direction
qualifiers of extensions under use. A session update MAY add or qualifiers of extensions under use. A session update MAY add or
remove extension(s). Identifiers values in the valid range MUST NOT remove extension(s). Identifiers values in the valid range MUST NOT
be altered (remapped). be altered (remapped).
Note that, under this rule, the same local identifier cannot be used Note that, under this rule, the same local identifier cannot be used
for two extensions for the same media, even when one is "sendonly" for two extensions for the same media, even when one is "sendonly"
and the other "recvonly", as it would then be impossible to make and the other "recvonly", as it would then be impossible to make
either of them sendrecv (since re-numbering is not permitted either). either of them sendrecv (since re-numbering is not permitted either).
If a party wishes to offer mutually exclusive alternatives, then If a party wishes to offer mutually exclusive alternatives, then
skipping to change at page 15, line 50 skipping to change at page 16, line 9
a bundle group are considered to be part of the same local identifier a bundle group are considered to be part of the same local identifier
(ID) space. If an RTP header extension, i.e. a particular extension (ID) space. If an RTP header extension, i.e. a particular extension
URI and configuration using <extensionattributes>, is offered in URI and configuration using <extensionattributes>, is offered in
multiple m-lines that are part of the same bundle group it MUST use multiple m-lines that are part of the same bundle group it MUST use
the same ID in all of these m-lines. Each m-line in a bundle group the same ID in all of these m-lines. Each m-line in a bundle group
can include different RTP header extensions allowing for example can include different RTP header extensions allowing for example
audio and video sources to use different sets of RTP header audio and video sources to use different sets of RTP header
extensions. It SHALL be assumed that for any RTP header extension, extensions. It SHALL be assumed that for any RTP header extension,
difference in configuration using any of the <extensionattributes> is difference in configuration using any of the <extensionattributes> is
important and need to be preserved to any receiver, thus requiring important and need to be preserved to any receiver, thus requiring
assignment of different IDs. Any RTP header extension that do not assignment of different IDs. Any RTP header extension that does not
match this assumption MUST explicitly provide rules for what are match this assumption MUST explicitly provide rules for what are
compatible configurations that can be sent with the same ID. The compatible configurations that can be sent with the same ID. The
directionality of the RTP header extensions in each m-line of the directionality of the RTP header extensions in each m-line of the
bundle group are handled as the non-bundled case. This allows for bundle group are handled as the non-bundled case. This allows for
specifying different directionality for each of the repeated specifying different directionality for each of the repeated
extension URI in bundled group. extension URI in bundled group.
8. BNF Syntax 8. BNF Syntax
The syntax definition below uses ABNF according to [RFC5234]. The The syntax definition below uses ABNF according to [RFC5234]. The
skipping to change at page 17, line 15 skipping to change at page 17, line 21
Extensions usage is negotiated using [RFC3264] so integrity Extensions usage is negotiated using [RFC3264] so integrity
protection and end-to-end authentication MUST be implemented. The protection and end-to-end authentication MUST be implemented. The
security considerations of [RFC3264] MUST be followed, to prevent, security considerations of [RFC3264] MUST be followed, to prevent,
for example, extension usage blocking. for example, extension usage blocking.
Header extensions have the same security coverage as the RTP header Header extensions have the same security coverage as the RTP header
itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is
used to protect RTP sessions, the RTP payload can be both encrypted used to protect RTP sessions, the RTP payload can be both encrypted
and integrity protected, while the RTP header is either unprotected and integrity protected, while the RTP header is either unprotected
or integrity protected. In order to prevent DOS attacks, for or integrity protected. In order to prevent DOS attacks, for
example, by changing the header extension integrity protection SHOULD example, by changing the header extension, integrity protection
be used. Lower layer security protection like DTLS[RFC6347] MAY be SHOULD be used. Lower layer security protection like DTLS[RFC6347]
used. RTP header extensions can carry sensitive information for MAY be used. RTP header extensions can carry sensitive information
which participants in multimedia sessions want confidentiality. for which participants in multimedia sessions want confidentiality.
RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of
SRTP, to selectively encrypt RTP header extensions in SRTP. SRTP, to selectively encrypt RTP header extensions in SRTP.
The RTP application designer needs to consider their security needs, The RTP application designer needs to consider their security needs,
that includes cipher strength for SRTP packets in general and what that includes cipher strength for SRTP packets in general and what
that means for the integrity and confidentiality of the RTP header that means for the integrity and confidentiality of the RTP header
extensions. As defined by RFC6904 [RFC6904] the encryption stream extensions. As defined by RFC6904 [RFC6904] the encryption stream
cipher for the header extension is dependent on the chosen SRTP cipher for the header extension is dependent on the chosen SRTP
cipher. It can be noted that the default SRTP ciphers (AES CM 128 cipher.
bits with HMAC-SHA1) are relative weak and more modern ciphers are
stronger and should be considered.
Other security options for securing RTP are discussed in [RFC7201]. Other security options for securing RTP are discussed in [RFC7201].
10. IANA Considerations 10. IANA Considerations
This document updates the IANA consideration to reference this This document updates the IANA consideration to reference this
document and adds a new SDP attribute in section 10.3 document and adds a new SDP attribute in section 10.3
Note to IANA : change RFCxxxx to this RFC number and remove the note. Note to IANA : change RFCxxxx to this RFC number and remove the note.
skipping to change at page 20, line 16 skipping to change at page 20, line 20
o Usage Level: Media or session level. o Usage Level: Media or session level.
o Charset Dependent: no. o Charset Dependent: no.
o Purpose: Negotiate the use of One and Two bytes in the same RTP o Purpose: Negotiate the use of One and Two bytes in the same RTP
stream. stream.
o O/A Procedures: See section 6 of [RFCXXXX]. o O/A Procedures: See section 6 of [RFCXXXX].
o Mux Category: Normal o Mux Category: Identical
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
11. Changes from RFC5285 11. Changes from RFC5285
The major motivation for updating [RFC5285] was to allow having one The major motivation for updating [RFC5285] was to allow having one
byte and two bytes RTP header extensions in the same RTP stream (but byte and two bytes RTP header extensions in the same RTP stream (but
not in the same RTP packet). The support for this case is negotiated not in the same RTP packet). The support for this case is negotiated
using a new SDP attribute "extmap-allow-mixed" specified in this using a new SDP attribute "extmap-allow-mixed" specified in this
document. document.
The other major change is to update the requirement from the RTP The other major change is to update the requirement from the RTP
specification and[RFC5285] that the header extension "is designed so specification [RFC3550] and [RFC5285] that the header extension "is
that the header extension MAY be ignored". This is described in designed so that the header extension MAY be ignored". This is
section 4.1. described in section 4.1.
The transmission consideration section (4.1.1) adds more text to The transmission consideration section (4.1.1) adds more text to
clarify when and how many times to send the RTP header extension to clarify when and how many times to send the RTP header extension to
provide higher probability of delivery provide higher probability of delivery
>The security section was expanded >The security section was expanded
The rest of the changes are editorial. The rest of the changes are editorial.
12. Acknowledgments 12. Acknowledgments
skipping to change at page 23, line 6 skipping to change at page 23, line 6
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
 End of changes. 23 change blocks. 
31 lines changed or deleted 37 lines changed or added

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