Internet DRAFT - draft-mandyam-rtcweb-fecframebundledssrc
draft-mandyam-rtcweb-fecframebundledssrc
Rtcweb Working Group G. Mandyam
Internet-Draft Qualcomm Innovation Center
Intended status: Informational M. Luby
Expires: December 18, 2015 Qualcomm Technologies Inc.
T. Stockhammer
Qualcomm CDMA Technologies GMBH
June 16, 2015
FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources
draft-mandyam-rtcweb-fecframebundledssrc-00
Abstract
The FEC FRAME Raptor code options do not currently address the case
of bundled protection of multiple media types over multiple real-time
transport protocol (RTP) synchronization sources (SSRC's). This
document provides the FEC source and repair payload definitions that
enable a single repair flow to be defined for multiple RTP flows
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Mandyam, et al. Expires December 18, 2015 [Page 1]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multi-sequenced Flows with Explicit Source FEC Payload ID . . 2
2.1. RTP Header Extension for Source FEC Payload ID . . . . . 3
2.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 3
2.3. New RTP Header Extension URI's . . . . . . . . . . . . . 3
3. Multi-sequenced Flows without Source FEC Payload ID . . . . . 3
3.1. Source FEC Payload ID . . . . . . . . . . . . . . . . . . 4
3.2. Repair FEC Payload ID . . . . . . . . . . . . . . . . . . 4
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Source Symbol Contruction . . . . . . . . . . . . . . 5
3.3.2. Derivations of Source FEC Packet Identification
Information . . . . . . . . . . . . . . . . . . . . . 5
3.3.3. Procedures for RTP Source Flows . . . . . . . . . . . 6
4. Registration of the 'bundled/raptorfec' Media Type . . . . . 6
5. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. With RTP Extensions . . . . . . . . . . . . . . . . . . . 7
5.2. Without RTP Extensions . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC6681] provides the specification of the fully formed Forward
Error Correction (FEC) scheme for Raptor/RaptorQ codes in the context
of the FEC Framework (FEC Frame - see [RFC6363]). This document
provides extensions that allow for protection of multiple RTP flows
where each flow has its own unique sequence number space. There are
two approaches described: one using explicit source FEC payload ID's,
and one that does not.
2. Multi-sequenced Flows with Explicit Source FEC Payload ID
As per Section 6 of [RFC6681], arbitrary flows (including RTP flows)
can be protected if the source is identified explicitly using a
Source FEC Payload ID. However, the Source FEC Payload ID must be
sent along with the source payload to the receiver.
Mandyam, et al. Expires December 18, 2015 [Page 2]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
2.1. RTP Header Extension for Source FEC Payload ID
It is recommended that the Source FEC Payload ID as defined in
Section 6.2.2 of [RFC6681] be used in an RTP header extension for
each RTP source stream packet. Since the Source FEC Payload ID is 32
bits long (4 bytes), the 1-byte header extension solution in
Section 4.2 of [RFC5285] is sufficient for identifying the Source FEC
Payload ID. Note however that there may be reasons to use the 2-byte
header extension solution provided in Section 4.3 of [RFC5285] (e.g.
due to the need for 8-bit extension ID encoding).
2.2. Repair FEC Payload ID
The Repair FEC Payload ID is used as defined in Section 6.2.3 of
[RFC6681]. This will be sent along with the associated repair
payload in a repair FEC stream (i.e. RTP flow). This can also be
sent as a RTP header extension (although it can be included in the
RTP payload of the repair FEC stream). As with the Source FEC
Payload ID, the 1-byte header extension method is preferred.
2.3. New RTP Header Extension URI's
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
This document defines two new extension URI's in the RTP Compact
Header Extensions subregistry of the Real-Time Transport Protocol
(RTP) Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:SourceID
Description: Source FEC Payload ID
Contact: mandyam@quicinc.com
Reference: RFCXXXX
Extension URI: urn:ietf:params:rtp-hdrext:FEC-FR:RepairID
Description: Repair FEC Payload ID
Contact: mandyam@quicinc.com
Reference: RFCXXXX
3. Multi-sequenced Flows without Source FEC Payload ID
Section 8 of [RFC6681] describes the necessary procedures for single-
sequenced flows. This section extends this method for multi-
sequenced flows, in particular multiple RTP flows corresponding to
different SSRC's. The FEC Scheme ID's used are 5 and 6.
Mandyam, et al. Expires December 18, 2015 [Page 3]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
3.1. Source FEC Payload ID
As with the approach provided in [RFC6681] for single-sequenced
flows, a source FEC Payload ID is not used as the source packets are
not modified.
3.2. Repair FEC Payload ID
In contrast to Section 8.1.3 of [RFC6681], only one format for the
Repair FEC Payload is provided (based on Format A), but with
necessary extensions for multi-sequenced flows. The number of flows
in a repair packet and the order in which the flows appear in the
repair packet are determined using out-of-band signalling (for an SDP
example, see Section 5.2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Sub-Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence Number | Source Sub-Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Repair FEC Payload ID (multisequence)
Figure 1
Initial Sequence Number (Flow i ISN), (16 bits): This field
specifies the lowest 16 bits of the sequence number of the
first packet to be included in this sub-block. If the sequence
numbers are shorter than 16 bits, then the received Sequence
Number SHALL be logically padded with zero bits to become 16
bits in length, respectively. The field type is unsigned
integer.
Source Sub-Block Length (SSBL), (16 bits): This field specifies the
length of the source sub-block in symbols. The field type is
unsigned integer.
Encoding Symbol ID (ESI), (16 bits): This field indicates which
repair symbols are contained within this repair packet. The
ESI provided is the ESI of the first repair symbol in the
packet. The field type is unsigned integer.
Mandyam, et al. Expires December 18, 2015 [Page 4]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
3.3. Procedures
There are slight changes necessary to the procedures outlined in
Section 8.2 of [RFC6681] in order to accomodate multiple sequenced
flows.
3.3.1. Source Symbol Contruction
FEC Scheme 5 and FEC Scheme 6 use the procedures defined in Section 5
of [RFC6681] to construct a set of source symbols to which the FEC
code can be applied.
During the construction of the source block:
o the flow identifier, f[i], for each flow included in the source
packet information.
o the length indication, l[i], included in the Source Packet
Information for each packet shall be dependent on the protocol
carried within the transport payload. Rules for RTP are specified
below.
o the value of s[i] in the construction of the Source Packet
Information for each packet shall be the smallest integer such
that s[i]*T >= (l[i]+3).
3.3.2. Derivations of Source FEC Packet Identification Information
The Source FEC Packet Identification Information for a source packet
is derived from the flows in each packet, sequence number of each
individual flow of the packet, and information received in any repair
FEC packet belonging to this source block. The application data
units (ADU's) that constitute the source block are identified by the
associated flow identifier and sequence number of the first source
packet in the block. This information is signaled in all repair FEC
packets associated with the source block in the Initial Sequence
Number field.
The length of the Source Packet Information (in octets) for source
packets within a source block is equal to the length of the payload
containing encoding symbols of the repair packets (i.e., not
including the Repair FEC Payload ID) for that block, which MUST be
the same for all repair packets. The Application Data Unit
Information Length (ADUIL) in symbols is equal to this length divided
by the encoding symbol size (which is signaled in the FEC Framework
Configuration Information). The set of source packets included in
the source block is determined by the Initial Sequence Number (ISN)
and Source Sub-Block Length (SSBL) as follows:
Mandyam, et al. Expires December 18, 2015 [Page 5]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
Let,
o f be the index of the flow, i.e. if f refers to the first flow in
the source block then f=1.
o I(f) be the Initial Sequence Number of the source sub-block from
flow f
o LP(f) be the Source Sub-Block Information Length in symbols for
flow f
o LB(f) be the Source Sub-Block Length in symbols for flow f
Then, source packets with sequence numbers from I(f) to I(f)
+(LB(f)/LP(f))-1 for flow f inclusive are included in the source
block. The Source Sub-Block Length, LB(f), MUST be chosen such that
it is at least as large as the largest Source Packet Information
Length LP(f).
Note that if no FEC repair packets are received, then no FEC decoding
is possible, and it is unnecessary for the receiver to identify the
Source FEC Packet Identification Information for the source packets.
For FEC Scheme 1, the ESI value placed into a repair packet is
calculated as specified in Section 5.3.2 of [RFC5053].
For FEC Scheme 2, the ESI value placed into a repair packet is
calculated as specified in Section 4.4.2 of [RFC6330].
In both cases, K is identical to the sum of all the SSBL's indicated
in the repair packet.
3.3.3. Procedures for RTP Source Flows
In the specific case of RTP source packet flows, the RTP Sequence
Number field SHALL be used as the sequence number in the procedures
described above. The length indication included in the Application
Data Unit Information SHALL be the sum over all flows of the RTP
payload length plus the length of the contributing sources (CSRCs),
if any, the RTP Header Extension, if present, and the RTP padding
octets, if any. Note that this length is always equal to the UDP
payload length of the packet minus 12.
4. Registration of the 'bundled/raptorfec' Media Type
This RTP payload format is identified using the 'bundled/raptorfec'
media type that is registered in accordance with [RFC4855] and uses
Mandyam, et al. Expires December 18, 2015 [Page 6]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
the template of [RFC4288]. The Media Type Definition is identical to
'video/raptorfec' and can be found in Section 6.2.1 of [RFC6682].
5. SDP Example
5.1. With RTP Extensions
An SDP example employing bundled protection of a video and audio
stream (derived from Section 10 of [RFC6681]) is shown below. In
this example, the SDP guidance provided in Section 5 of [RFC5285] is
also used.
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor FEC Example
t=0 0
a=group:FEC-FR S1 S2 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID
m=audio 10000 RTP/AVP 0 8 97
c=IN IP4 233.252.0.2/127
b=AS:200
a=rtpmap:0 PCMU/8000
a=mid:S2
a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:SourceID
a=fec-source-flow: id=1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A
a=repair-window:200ms
a=mid:R1
a=extmap:1 urn:ietf:params:rtp-hdrext:FEC-FR:RepairID
5.2. Without RTP Extensions
An SDP example employing bundled protection of a video and audio
stream (derived from Section 10 of [RFC6681]) is shown below. In
this example, source flows (S1 and S2) identified in the 'a=group'
attirbute appear in this order in the Repair FEC Payload ID (see
Figure 1).
Mandyam, et al. Expires December 18, 2015 [Page 7]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor FEC Example
t=0 0
a=group:FEC-FR S1 S2 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=audio 10000 RTP/AVP 0 8 97
c=IN IP4 233.252.0.2/127
b=AS:200
a=rtpmap:0 PCMU/8000
a=mid:S2
a=fec-source-flow: id=1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=6; fssi=Kmax:8192,T:128,P:A
a=repair-window:200ms
a=mid:R1
6. IANA Considerations
This memo includes no request to IANA.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, October 2007.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
Mandyam, et al. Expires December 18, 2015 [Page 8]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
and L. Minder, "RaptorQ Forward Error Correction Scheme
for Object Delivery", RFC 6330, August 2011.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6364] Begen, A., "Session Description Protocol Elements for the
Forward Error Correction (FEC) Framework", RFC 6364,
October 2011.
[RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward
Error Correction (FEC) Schemes for FECFRAME", RFC 6681,
August 2012.
[RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload
Format for Raptor Forward Error Correction (FEC)", RFC
6682, August 2012.
Authors' Addresses
Giridhar Mandyam
Qualcomm Innovation Center
5775 Morehouse Drive
San Diego, California 92121
USA
Phone: +1 858 651 7200
Email: mandyam@quicinc.com
Mike Luby
Qualcomm Technologies Inc.
2030 Addison Street
Berkeley, California 94704
USA
Phone: +1 510 725 3502
Email: luby@qti.qualcomm.com
Mandyam, et al. Expires December 18, 2015 [Page 9]
Internet-Draft FECFRAME4MultipleSSRCs June 2015
Thomas Stockhammer
Qualcomm CDMA Technologies GMBH
Franziskanerstrasse 14
Munich 81669
Germany
Phone: +49 86190959757
Email: tsto@qti.qualcomm.com
Mandyam, et al. Expires December 18, 2015 [Page 10]
