draft-ietf-avtext-sdes-hdr-ext-00.txt   draft-ietf-avtext-sdes-hdr-ext-01.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft B. Burman Internet-Draft B. Burman
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: September 24, 2015 R. Even Expires: November 12, 2015 R. Even
Huawei Technologies Huawei Technologies
M. Zanaty M. Zanaty
Cisco Systems Cisco Systems
March 23, 2015 May 11, 2015
RTP Header Extension for RTCP Source Description Items RTP Header Extension for RTCP Source Description Items
draft-ietf-avtext-sdes-hdr-ext-00 draft-ietf-avtext-sdes-hdr-ext-01
Abstract Abstract
Source Description (SDES) items are normally transported in RTP Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed control protocol (RTCP). In some cases it can be beneficial to speed
up the delivery of these items. Mainly when a new source (SSRC) up the delivery of these items. Mainly when a new source (SSRC)
joins an RTP session and the receivers needs this source's relation joins an RTP session and the receivers needs this source's identity,
to other sources and its synchronization context, which are fully or relation to other sources, or its synchronization context, all of
partially identified using SDES items. To enable this optimization, which may be fully or partially identified using SDES items. To
this document specifies a new RTP header extension that can carry any enable this optimization, this document specifies a new RTP header
type of SDES items. extension that can carry SDES items.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 24, 2015. This Internet-Draft will expire on November 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 18 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 5 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 6 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 6
4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 8 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 8
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Reservation of the SDES URN sub-space . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Registration of SDES Items . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This specification defines an RTP header extension [RFC3550][RFC5285] This specification defines an RTP header extension [RFC3550][RFC5285]
that can carry RTCP source description (SDES) items. By including that can carry RTCP source description (SDES) items. By including
selected SDES items in an header extension the determination of selected SDES items in an header extension the determination of
relationship and synchronization context for new RTP streams (SSRCs) relationship and synchronization context for new RTP streams (SSRCs)
in an RTP session can be speeded up. Which relationship and what in an RTP session can be speeded up. Which relationship and what
information depends on the SDES items carried. This becomes a information depends on the SDES items carried. This becomes a
complement to using only RTCP for SDES Item delivery. complement to using only RTCP for SDES Item delivery.
First, some requirements language is defined. The following section It is important to note that not all SDES items are appropriate to
motivates why this header extension is sometimes required or at least transmit using RTP header extensions. Some SDES items performs
provides a significant improvement compared to waiting for regular binding or identifies synchronization context with strict timeliness
RTCP packet transmissions of the information. This is followed by a requirements, while many other SDES items do not have such
specification of the header extension. Next, a sub-space of the requirements. In addition, security and privacy concerns for the
header-extension URN is defined to be used for existing and future SDES item information needs to be considered. For example, the Name
SDES items, and the existing SDES items are registered. and Location SDES items are highly sensitive from a privacy
perspective and should not be transported over the network without
strong security. No use case has identified where this information
is required at the same time as the first RTP packets arrive. A few
seconds delay before such information is available to the receiver
appears acceptable. Therefore only appropriate SDES items will be
registered for use with this header extension, such as CNAME.
First, some requirements language and terminology is defined. The
following section motivates why this header extension is sometimes
required or at least provides a significant improvement compared to
waiting for regular RTCP packet transmissions of the information.
This is followed by a specification of the header extension and usage
recommendations. Next, a sub-space of the header-extension URN is
defined to be used for existing and future SDES items, and then the
appropriate SDES items are registered.
2. Definitions 2. Definitions
2.1. Requirements Language 2.1. Requirements Language
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
This document uses terminology defined in "A Taxonomy of Grouping This document uses terminology defined in "A Taxonomy of Grouping
Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Semantics and Mechanisms for Real-Time Transport Protocol (RTP)
Sources" [I-D.ietf-avtext-rtp-grouping-taxonomy] . In particular the Sources" [I-D.ietf-avtext-rtp-grouping-taxonomy]. In particular the
following definitions: following definitions:
Media Source Media Source
RTP Stream RTP Stream
Media Encoder Media Encoder
Encoded Stream Encoded Stream
Participant Participant
3. Motivation 3. Motivation
Source Description (SDES) items are being associated with a Source Description (SDES) items are associated with a particular SSRC
particular SSRC and thus RTP stream. The source description items and thus RTP stream. The source description items provide various
provide various meta data associated with the SSRC. How important it meta data associated with the SSRC. How important it is to have this
is to have this data no later than when receiving the first RTP data no later than when receiving the first RTP packets depends on
packets depends on the item itself. The CNAME item is one item that the item itself. The CNAME item is one item that is commonly needed
is commonly needed if not at reception of the first RTP packet for if not at reception of the first RTP packet for this SSRC, then at
this SSRC, so at least by the time the first media can be played out. least by the time the first media can be played out. If not, the
If not, the synchronization context cannot be determined and thus any synchronization context cannot be determined and thus any related
related streams cannot be correctly synchronized. Thus, this is a streams cannot be correctly synchronized. Thus, this is a valuable
great example for the need to have this information early when a new example for having this information early when a new RTP stream is
RTP stream is received. received.
The main reason for new SSRCs in an RTP session is that a media The main reason for new SSRCs in an RTP session is when media sources
sources are added. This either because an end-point is adding a new are added. This either because an end-point is adding a new actual
actual media source, or additional participants in a multi-party media source, or additional participants in a multi-party session are
session being added to the session. Another reason for a new SSRC added to the session. Another reason for a new SSRC can be an SSRC
can be an SSRC collision that forces the colliding parties to select collision that forces both colliding parties to select new SSRCs.
a new SSRC.
Returning to the case of rapid media synchronization, there exist an For the case of rapid media synchronization, one may use the RTP
RTP header extension for Rapid Synchronization of RTP Flows header extension for Rapid Synchronization of RTP Flows [RFC6051].
[RFC6051]. That header extension carries the clock information This header extension carries the clock information present in the
present in the RTCP sender report (SR) packets. It however assumes RTCP sender report (SR) packets. It however assumes that the CNAME
that the CNAME binding is known, which can be provided via signaling binding is known, which can be provided via signaling in some cases,
in some cases, but not all. Thus an RTP header extension for but not all. Thus an RTP header extension for carrying SDES items
carrying SDES items like CNAME is a powerful combination to enable like CNAME is a powerful combination to enable rapid synchronization
rapid synchronization in all cases. in all cases.
The Rapid Synchronization of RTP Flows specification does provide an The Rapid Synchronization of RTP Flows specification does provide an
analysis of the initial synchronization delay for different sessions analysis of the initial synchronization delay for different sessions
depending on number of receivers as well as on session bandwidth depending on number of receivers as well as on session bandwidth
(Section 2.1 of [RFC6051]). These results are applicable also for (Section 2.1 of [RFC6051]). These results are applicable also for
other SDES items that have a similar time dependency until the other SDES items that have a similar time dependency until the
information can be sent using RTCP. Thus the benefit for reduction information can be sent using RTCP. Thus the benefit of reducing the
of initial delay before information is available can be determined initial delay before information is available can be determined for
for some use cases from these figures. some use cases from these figures.
That document also discusses the case of late joiners, and defines an That document also discusses the case of late joiners, and defines an
RTCP Feedback format to request synchronization information, which is RTCP Feedback format to request synchronization information, which is
another potential use case for SDES items in RTP header extension. another potential use case for SDES items in RTP header extension.
It would for example be natural to include CNAME SDES item with the It would for example be natural to include CNAME SDES item with the
header extension containing the NTP formatted reference clock to header extension containing the NTP formatted reference clock to
ensure synchronization. ensure synchronization.
Some new SDES items are currently proposed, which can all benefit There is an additional, newly defined SDES item that can benefit from
from timely delivery: timely delivery, and an RTP header extension SDES item is therefore
defined for it:
MID: This is a media description identifier that matches the value MID: This is a media description identifier that matches the value
of the SDP a=mid attribute, to associate RTP streams multiplexed of the SDP a=mid attribute, to associate RTP streams multiplexed
on the same transport with their respective SDP media description on the same transport with their respective SDP media description
as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. as described in [I-D.ietf-mmusic-sdp-bundle-negotiation].
SRCNAME: This is a media source and encoding identifier to enable
support for simulcast and improve some scalable encoding usages
[I-D.westerlund-avtext-rtcp-sdes-srcname]. This SDES item could
be used both for new sources and late joiners.
APPID: This SDES item provides an application specific identifier
dynamically assigned to a particular RTP stream. The intention is
to provide a receiver with information about the current role of
the received RTP stream or its usage in an application
[I-D.even-mmusic-application-token]. Thus a particular ID can be
reassigned many times during the lifetime of an RTP session. This
puts additional timing requirements, not only for new sources and
late joiners, but also whenever the Application token is
reassigned to another stream.
Based on the above, there appear to be good reasons why an RTP header
extension for SDES items is worthwhile to pursue.
4. Specification 4. Specification
This section first specifies the SDES item RTP header extension This section first specifies the SDES item RTP header extension
format, followed by some usage considerations. format, followed by some usage considerations.
4.1. SDES Item Header Extension 4.1. SDES Item Header Extension
The RTP header extension scheme that allows for multiple extensions The RTP header extension scheme that allows for multiple extensions
to be included is defined in "A General Mechanism for RTP Header to be included is defined in "A General Mechanism for RTP Header
Extensions" [RFC5285]. That specification defines both short and Extensions" [RFC5285]. That specification defines both short and
long item headers. The short headers (One-byte) are restricted to 1 long item headers. The short headers (One-byte) are restricted to 1
to 16 bytes of data, while the long format (Two-byte) supports a data to 16 bytes of data, while the long format (Two-byte) supports a data
length of 0 to 255 bytes. Thus that RTP header extension format is length of 0 to 255 bytes. Thus the RTP header extension formats are
capable of supporting any SDES item from a data length perspective. capable of supporting any SDES item from a data length perspective.
The ID field, independent of short or long format, identifies both The ID field, independent of short or long format, identifies both
the type of RTP header extension and, in the case of the SDES item the type of RTP header extension and, in the case of the SDES item
header extension, the type of SDES item. The mapping is done in header extension, the type of SDES item. The mapping is done in
signaling by identifying the header extension and SDES item type signaling by identifying the header extension and SDES item type
using a URN, which is defined in the IANA consideration (Section 5) using a URN, which is defined in the IANA consideration (Section 5)
for all existing SDES items. for the known SDES items appropriate to use.
4.1.1. One-Byte Format 4.1.1. One-Byte Format
The one-byte header format for an SDES item extension element The one-byte header format for an SDES item extension element
consists of the One-Byte header (defined in Section 4.2 of consists of the One-Byte header (defined in Section 4.2 of
[RFC5285]), which consists of a 4-bit ID followed by a 4-bit length [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length
field (len) that identifies how many bytes (len value +1) of data field (len) that identifies how many bytes (len value +1) of data
that follows the header. The data part consists of len+1 bytes of following the header. The data part consists of len+1 bytes of UTF-8
UTF-8 text. The type of text is determined by the ID field value and text. The type of text is determined by the ID field value and its
its mapping to the type of SDES item. mapping to the type of SDES item.
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 | len | SDES Item text value ... | | ID | len | SDES Item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
4.1.2. Two-Byte Format 4.1.2. Two-Byte Format
skipping to change at page 6, line 27 skipping to change at page 6, line 33
4.2. Usage of the SDES Item Header Extension 4.2. Usage of the SDES Item Header Extension
This section discusses various usage considerations; which form of This section discusses various usage considerations; which form of
header extension to use, the packet expansion, and when to send SDES header extension to use, the packet expansion, and when to send SDES
items in header extension. items in header extension.
4.2.1. One or Two Byte Headers 4.2.1. One or Two Byte Headers
The RTP header extensions for SDES items MAY use either the one-byte The RTP header extensions for SDES items MAY use either the one-byte
or two-byte header formats, depending on the text value size for the or two-byte header formats, depending on the text value size for the
used SDES items. The one-byte header SHOULD be used when all non used SDES items and the requirement from any other header extensions
SDES item header extensions supports the one-byte format and all SDES used. The one-byte header SHOULD be used when all non SDES item
item text values contain at most 16 bytes. Note that the RTP header header extensions supports the one-byte format and all SDES item text
extension specification does not allow mixing one-byte and two-byte values contain at most 16 bytes. Note that the RTP header extension
headers for the same RTP stream (SSRC), so if the value size of any specification does not allow mixing one-byte and two-byte headers for
of the SDES items value requires the two-byte header, the all other the same RTP stream (SSRC), so if the value size of any of the SDES
header extensions MUST also use the two-byte header format. items value requires the two-byte header, the all other header
extensions MUST also use the two-byte header format.
For example using CNAMEs that are generated according to "Guidelines For example using CNAMEs that are generated according to "Guidelines
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)"
[RFC7022], using short term persistent values, and if 96-bit random [RFC7022], using short term persistent values, and if 96-bit random
values prior to base64 encoding are sufficient, then they will fit values prior to base64 encoding are sufficient, then they will fit
into the One-Byte header format. into the One-Byte header format.
4.2.2. MTU and Packet Expansion 4.2.2. MTU and Packet Expansion
The RTP packet size will clearly increase when they include the The RTP packet size will clearly increase when it includes the header
header extension. How much depends on which header extensions and extension. How much depends on which header extensions and their
their data parts. The SDES items can vary in size. There are also data parts. The SDES items can vary in size. There are also some
some use-cases which require transmitting multiple SDES items in the use-cases which require transmitting multiple SDES items in the same
same packet to ensure that all relevant data reaches the receiver. packet to ensure that all relevant data reaches the receiver. An
An example of that is when you need both the CNAME, a SRCNAME and an example of that is when you need both the CNAME, a MID, and the rapid
appId plus the rapid time synchronization extension from RFC 6051. time synchronization extension from RFC 6051. Such a combination is
Such a combination is quite likely to result in at least 16+3+1+8 quite likely to result in at least 16+3+8 bytes of data plus the
bytes of data plus the headers, which will be another 8 bytes for headers, which will be another 7 bytes for one-byte headers plus two
one-byte headers, thus in total 36 bytes. bytes of padding headers to make the complete header extension word
aligned, thus in total 36 bytes.
The packet expansion can cause an issue when it cannot be taken into The packet expansion can cause an issue when it cannot be taken into
account when producing the RTP payload. Thus an RTP payload that is account when producing the RTP payload. An RTP payload that is
created to meet a particular IP level Maximum Transmission Unit created to meet a particular IP level Maximum Transmission Unit
(MTU), taking the addition of IP/UDP/RTP headers into account but (MTU), taking the addition of IP/UDP/RTP headers but not RTP header
excluding RTP header extensions suddenly exceeds the MTU, resulting extensions into account could exceed the MTU when the header
in IP fragmentation. IP fragmentation is known to negatively impact extensions are present, thus resulting in IP fragmentation. IP
the loss rate due to middleboxes unwilling or not capable of dealing fragmentation is known to negatively impact the loss rate due to
with IP fragments. middleboxes unwilling or not capable of dealing with IP fragments, as
well as increasing the target surface for other types of packet
losses.
As this is a real issue, the media encoder and payload packetizer As this is a real issue, the media encoder and payload packetizer
should be flexible and be capable of handling dynamically varying should be flexible and be capable of handling dynamically varying
payload size restrictions to counter the packet expansion caused by payload size restrictions to counter the packet expansion caused by
header extensions. If that is not possible, some reasonable worst header extensions. If that is not possible, some reasonable worst
case packet expansion should be calculated and used to reduce the RTP case packet expansion should be calculated and used to reduce the RTP
payload size of all RTP packets the sender transmits. payload size of all RTP packets the sender transmits.
4.2.3. Transmission Considerations 4.2.3. Transmission Considerations
The general recommendation is to only send header extensions when The general recommendation is to only send header extensions when
needed. This is especially true for SDES items that can be sent in needed. This is especially true for SDES items that can be sent in
periodic repetitions of RTCP throughout the whole session. Thus, the periodic repetitions of RTCP throughout the whole session. Thus, the
different usages (Section 4.2.4) have different recommendations. different usages (Section 4.2.4) have different recommendations.
First some general considerations for getting the header extensions First some general considerations for getting the header extensions
delivered to the receiver: delivered to the receiver:
1. The probability for packet loss and burst loss determine how many 1. The probability for packet loss and burst loss determine how many
repetitions of the header extensions will be required to reach a repetitions of the header extensions will be required to reach a
targeted delivery probability, and if bust loss is likely what targeted delivery probability, and if burst loss is likely what
dispersion would be needed to avoid getting multiple header dispersion would be needed to avoid getting multiple header
extensions lost in a single burst. extensions lost in a single burst.
2. How early the SDES item information is needed, from the first 2. If a set of packets are all needed to enable decoding, there is
commonly no reason for including the header extension in all of
these packets, as they share fate. Instead, at most one instance
of the header extension per independently decodable set of media
data would be a more efficient use of the bandwidth.
3. How early the SDES item information is needed, from the first
received RTP data or only after some set of packets are received, received RTP data or only after some set of packets are received,
can guide if the header extension(s) should be in all of the can guide if the header extension(s) should be in all of the
first N packets or be included only once per set of packets, for first N packets or be included only once per set of packets, for
example once per video frame. example once per video frame.
3. The use of RTP level robustness mechanisms, such as RTP 4. The use of RTP level robustness mechanisms, such as RTP
retransmission [RFC4588], or Forward Error Correction, e.g., retransmission [RFC4588], or Forward Error Correction, e.g.,
[RFC5109] may treat packets differently from a robustness [RFC5109] may treat packets differently from a robustness
perspective, and SDES header extensions should be added to perspective, and SDES header extensions should be added to
packets that get a treatment corresponding to the relative packets that get a treatment corresponding to the relative
importance of receiving the information. importance of receiving the information.
In summary, the number of header extension transmissions should be In summary, the number of header extension transmissions should be
tailored to a desired probability of delivery taking the receiver tailored to a desired probability of delivery taking the receiver
population size into account. For the very basic case, N repetitions population size into account. For the very basic case, N repetitions
of the header extensions should be sufficient, but may not be of the header extensions should be sufficient, but may not be
optimal. N is selected so that probability of delivery of at least optimal. N is selected so that the header extension target delivery
one out of the N reaches the target value when calculating 1-P^N, probability reaches 1-P^N, where P is the probability of packet loss.
where P is the probability of packet loss. For point to point or For point to point or small receiver populations, it might also be
small receiver populations, it might also be possible to use possible to use feedback, such as RTCP, to determine when the
feedback, such as RTCP, to determine when the information in the information in the header extensions has reached all receivers and
header extensions has likely reached all receivers. stop further repetitions. Feedback that can be used includes the
RTCP XR Loss RLE report block [RFC3611], which will indicate
succesful delivery of particular packets. If the RTP/AVPF Transport
Layer Feedback Messages for generic NACK [RFC4585] is used, it can
indicate the failure to deliver an RTP packet with the header
extension, thus indicating the need for further repetitions. The
normal RTCP report blocks can also provide an indicator of succesful
delivery, if no losses are indicated for a reporting interval
covering the RTP packets with the header extension. Note that loss
of an RTCP packet reporting on an interval where RTP header extension
packets were sent, does not necessarily mean that the RTP header
extension packets themselves were lost.
4.2.4. Different Usages 4.2.4. Different Usages
4.2.4.1. New SSRC 4.2.4.1. New SSRC
A new SSRC joins an RTP session. As this SSRC is completely new for A new SSRC joins an RTP session. As this SSRC is completely new for
everyone, the goal is to ensure that all receivers with high everyone, the goal is to ensure, with high probability, that all
probability receives the information in the header extension. Thus receivers receives the information in the header extension. Thus,
header extension transmission strategies that allow some margins in header extension transmission strategies that allow some margins in
the delivery probability should be considered. the delivery probability should be considered.
4.2.4.2. Late Joiner 4.2.4.2. Late Joiner
In a multi-party RTP session where one or a small number of receivers In a multi-party RTP session where one or a small number of receivers
join a session where the majority of receivers already have all join a session where the majority of receivers already have all
necessary information, the use of header extensions to deliver necessary information, the use of header extensions to deliver
relevant information should be tailored to reach the new receivers. relevant information should be tailored to reach the new receivers.
The trigger to send header extensions can for example either be RTCP The trigger to send header extensions can for example either be RTCP
from new receiver(s) or an explicit request like the Rapid from new receiver(s) or an explicit request like the Rapid
Resynchronization Request defined in [RFC6051]. Resynchronization Request defined in [RFC6051]. In centralized
topologies where an RTP middlebox is present, it can be responsible
for transmitting the known information, possibly stored, to the new
session participant only, and not repeat it to all the session
participants.
4.2.4.3. Information Change 4.2.4.3. Information Change
In cases when the SDES item text value is changed and the new SDES In cases when the SDES item text value is changed and the new SDES
information is tightly coupled to and thus needs to be synchronized information is tightly coupled to and thus needs to be synchronized
with a related change in the RTP stream, use of a header extension is with a related change in the RTP stream, use of a header extension is
far superior to RTCP SDES. In this case it is equal or even more far superior to RTCP SDES. In this case it is equal or even more
important with timely SDES information than in the case of new SSRCs important with timely SDES information than in the case of new SSRCs
(Section 4.2.4.1). Continued use of the old SDES information can (Section 4.2.4.1). Continued use of the old SDES information can
lead to really undesired effects in the application. Application lead to undesired effects in the application. Thus, header extension
Token [I-D.even-mmusic-application-token] would be one such case. transmission strategies with high probability of delivery should be
Thus, header extension transmission strategies with high probability chosen.
of delivery should be chosen.
4.2.5. SDES Items in RTCP 4.2.5. SDES Items in RTCP
As this RTP header extensions information, i.e. SDES Items can and The RTP header extensions information, i.e. SDES Items, can and will
will be sent also in RTCP it is worth some reflections on this be sent also in RTCP. Therefore, it is worth some reflections on
interaction. There also exist the possibility to schedule a non- this interaction. An alternative to the header extension is the
regular RTCP packet transmission containing important SDES items if possibility to schedule a non-regular RTCP packet transmission
one uses a RTP/AVPF based RTP profile. Depending on which mode ones containing important SDES items, if one uses a RTP/AVPF based RTP
RTCP feedback transmitter is working on extra RTCP packets may be profile. Depending on which mode one's RTCP feedback transmitter is
sent as immediate or early packets, enabling more timely deliver of working on, extra RTCP packets may be sent as immediate or early
SDES information. packets, enabling more timely delivery of SDES information.
There is however two aspects that differ between using RTP header There is however two aspects that differ between using RTP header
extension and any non-regular transmission of RTCP packets. First, extensions and any non-regular transmission of RTCP packets. First,
as the RTCP packet is a separate packet, there is no direct relation as the RTCP packet is a separate packet, there is no direct relation
and also no fate sharing between the relevant media data and the SDES and also no fate sharing between the relevant media data and the SDES
information. The order of arrival for the packets will matter. With information. The order of arrival for the packets will matter. With
a header-extension the SDES items can be ensured to arrive if the a header-extension the SDES items can be ensured to arrive if the
media data to played out arrives. Secondly, it is difficult to media data to play out arrives. Secondly, it is difficult to
determine if an RTCP packet is actually delivered. This, as the RTCP determine if an RTCP packet is actually delivered. This, as the RTCP
packets lack both sequence number or a mechanism providing feedback packets lack both sequence number or a mechanism providing feedback
on the RTCP packets themselves. on the RTCP packets themselves.
4.2.6. Update Flaps
The SDES item may arrive both in RTCP and in RTP header extensions,
this can cause the value to flap back and forth at the time of
updating. There are at least two reasons for these flaps. The first
one is packet reordering, where a pre-update RTP or RTCP packet with
an SDES item is delivered to the receiver after the first RTP/RTCP
packet with the updated value. The second reason is the different
code-paths for RTP and RTCP in implementations. An update to the
senders SDES item parameter, can take different time to propagate.
For example an RTCP packet with the SDES item included, that may have
been generated prior to the update can still reside in a buffer and
be sent unmodified. The update of the item's value can at the same
time cause RTP packets to be sent including the header extension,
prior to the RTCP packet being sent.
However, most of these issues can be avoided by performing some
checks before updating the receiver's stored value. To handle flaps
caused by reordering, only SDES items received in RTP packets with a
higher extended sequence number than the last change shall be
applied, i.e. discard items that can be determined to be older than
the current one. For compound RTCP packets, which will contain an
Sender Report (SR) packet (assuming an active RTP sender), the
receiver can compare the RTCP Sender Report's Timestamp field, to
determine at what approximate time it was transmitted. If the
timestamp is earlier than the last received RTP packet extension
carrying an SDES item, and especially if carrying a previously used
value, the SDES item in the RTCP SDES packet can be ignored. Note,
that media processing and transmission pacing can easily cause the
RTP header timestamp field as well as the RTCP SR timestamp field to
only lously couple with the actual transmission time.
5. IANA Considerations 5. IANA Considerations
This IANA section firstly proposes to: This section makes the following requests to IANA:
o Reserve the SDES item RTP header extension defined in this o Register and reserve for SDES items the URN sub-space
document for use with current and future SDES items. "urn:ietf:params:rtp-hdrext:sdes:" in the RTP Compact Header
Extensions registry.
o Register and assign the URN sub-space "urn:ietf:params:rtp- o Register the SDES items appropriate for use with the RTP header
hdrext:sdes:" in the RTP Compact Header Extensions registry. extension defined in this document.
The reason to require registering a URN within that sub-space is that 5.1. Reservation of the SDES URN sub-space
the name represent an RTCP Source Description item, where a
The reason to require registering a URN within an SDES sub-space is
that the name represents an RTCP Source Description item, where a
specification is strongly recommended. The formal policy is specification is strongly recommended. The formal policy is
maintained from the main space, i.e. Expert Review. maintained from the main space, i.e. Expert Review. However, some
additional considerations are provided here that needs to be
considered when applying for a registration within this sub-space of
the RTP Compact Header Extensions registry.
Secondly, it is proposed that only the current existing SDES items Any registration using an Extension URI that starts with
that are critical for immediate media processing, and therefore "urn:ietf:params:rtp-hdrext:sdes:" MUST also have a registered Source
should fate share their delivery with RTP media, are registered for Description item in the "RTP SDES item types" registry. Secondly, a
usage in the RTP Compact Header Extensions registry : security and privacy consideration for the SDES item must be provided
with the registration, preferably in a publicly available reference.
Thirdly, information must be provided on why this SDES item requires
timely delivery, motivating it to be transported in an header
extension rather than as RTCP only.
URN SDES Item Reference IANA is requested to register the below in the RTP Compact Header
================================================================== Extensions:
urn:ietf:params:rtp-hdrext:sdes:cname CNAME [RFC3550]
Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for SDES items that are also
defined as RTP Compact header extensions.
Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX]
RFC-editor note: Please replace all occurances of RFCXXXX with the
RFC number this specification receives when published.
5.2. Registration of SDES Items
It is requested that the following SDES item is registered in the RTP
Compact Header Extensions registry:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier
(SDES CNAME)
Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX]
We also note that the MID SDES item is already registered in the
registry by [I-D.ietf-mmusic-sdp-bundle-negotiation].
6. Security Considerations 6. Security Considerations
Source Description items may contain data that are sensitive from a Source Description items may contain data that are sensitive from a
security perspective. There exist SDES items that are or may be security perspective. There are SDES items that are or may be
sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, sensitive from a user privacy perspective, like CNAME, NAME, EMAIL,
PHONE, LOC and H323-CADDR. Others may contain sensitive information PHONE, LOC and H323-CADDR. Some may contain sensitive information,
like NOTE and PRIV, while others may be sensitive from profiling like NOTE and PRIV, while others may be sensitive from profiling
implementations for vulnerability or other reasons, like TOOL. The implementations for vulnerability or other reasons, like TOOL. The
CNAME sensitivity can vary depending on how it is generated and what CNAME sensitivity can vary depending on how it is generated and what
persistence it has. A short term CNAME identifier generated using a persistence it has. A short term CNAME identifier generated using a
random number generator may have minimal security implications, while random number generator [RFC7022] may have minimal security
one of the form user@host has privacy concerns and one generated from implications, while a CNAME of the form user@host has privacy
a MAC address has long term tracking potentials. concerns, and a CNAME generated from a MAC address has long term
tracking potentials.
The above security concerns may have to be put in relation to needs The above security concerns may have to be put in relation to third
of third party monitoring. In RTP sessions where any type of party monitoring needs. In RTP sessions where any type of
confidentiality protection is enabled, the SDES item header confidentiality protection is enabled, the SDES item header
extensions SHOULD also be protected per default. This implies that extensions SHOULD also be protected per default. This implies that
to provide confidentiality, users of SRTP need to implement encrypted to provide confidentiality, users of SRTP need to implement encrypted
header extensions per [RFC6904]. Commonly, it is expected that the header extensions per [RFC6904]. Commonly, it is expected that the
same security level is applied both RTCP packets carrying SDES items, same security level is applied to RTCP packets carrying SDES items,
as a RTP header extension containing a SDES item. If the security and to an RTP header extension containing SDES items. If the
level is different it is important to consider the security security level is different, it is important to consider the security
properties as the worst in each aspect for the different properties as the worst in each aspect for the different
configurations. configurations.
As the SDES items are used by the RTP based application to establish As the SDES items are used by the RTP based application to establish
relationships between RTP streams or between an RTP stream and relationships between RTP streams or between an RTP stream and
information about the originating Participant, there SHOULD be strong information about the originating Participant, there SHOULD be strong
requirements on integrity and source authentication of the header requirements on integrity and source authentication of the header
extensions. If not, an attacker can modify the SDES item value to extensions. If not, an attacker can modify the SDES item value to
create erroneous relationship bindings in the receiving application. create erroneous relationship bindings in the receiving application.
skipping to change at page 11, line 14 skipping to change at page 13, line 7
[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, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April Real-time Transport Protocol (SRTP)", RFC 6904, April
2013. 2013.
8.2. Informative References 8.2. Informative References
[I-D.even-mmusic-application-token]
Even, R., Lennox, J., and Q. Wu, "The Session Description
Protocol (SDP) Application Token Attribute", draft-even-
mmusic-application-token-03 (work in progress), April
2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"A Taxonomy of Grouping Semantics and Mechanisms for Real- B. Burman, "A Taxonomy of Grouping Semantics and
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Mechanisms for Real-Time Transport Protocol (RTP)
rtp-grouping-taxonomy-06 (work in progress), March 2015. Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work
in progress), March 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-18 (work in progress), March 2015. negotiation-19 (work in progress), March 2015.
[I-D.westerlund-avtext-rtcp-sdes-srcname] [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Westerlund, M., "RTCP Source Description Item SRCNAME to Protocol Extended Reports (RTCP XR)", RFC 3611, November
Label Individual Media Sources", draft-westerlund-avtext- 2003.
rtcp-sdes-srcname-03 (work in progress), October 2013.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006.
[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,
July 2006. July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", RFC 6776, October 2012.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Stockholm SE-164 80 Stockholm
skipping to change at page 12, line 19 skipping to change at page 14, line 4
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE-164 80 Stockholm Stockholm 16480
Sweden Sweden
Phone: +46 10 714 13 11
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Mo Zanaty Mo Zanaty
 End of changes. 54 change blocks. 
175 lines changed or deleted 257 lines changed or added

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