RFC 6682

RTP Payload Format for Raptor Forward Error Correction (FEC)

📅 published August 2012, from ietf

RFC 6682: RTP Payload Format for Raptor Forward Error Correction (FEC) 🎀

Part 1 of 3! Bestie, this is the first chunk. The rest is coming. 💅

Title block facts 📋

  • Series: Internet Engineering Task Force (IETF), Request for Comments 6682
  • Authors: M. Watson (Netflix), T. Stockhammer (Nomor Research), M. Luby (Qualcomm Incorporated)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: August 2012
  • Obsoletes and updates: the title block doesn't list anything this document obsoletes or updates

Abstract ✨

Okay bestie, so this doc defines an RTP payload format for the Forward Error Correction (FEC) repair data made by the Raptor FEC Schemes. 🦋 Those schemes are built for the IETF FEC Framework, which can carry repair data over both UDP and RTP. The whole point here is spelling out the payload format you need if you want to use RTP to carry Raptor repair flows. 🫶

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). 👑 For more on Internet Standards, check out Section 2 of RFC 5741.

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6682. 🍓

Copyright (c) 2012 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. 📖 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Simplified BSD License describes.

Table of Contents 🧚

1. Introduction ....................................................3
2. Conventions, Definitions, and Acronyms ..........................3
3. Media Format Background .........................................3
4. Payload Format for FEC Repair Packets ...........................4
   4.1. RTP Header Usage ...........................................4
   4.2. Payload Header .............................................5
   4.3. Payload Data ...............................................5
5. Congestion Control Considerations ...............................5
6. Media Types .....................................................5
   6.1. Registration of the 'application/raptorfec' Media Type .....5
        6.1.1. Media Type Definition ...............................5
   6.2. Registration of the 'video/raptorfec' Media Type ...........7
        6.2.1. Media Type Definition ...............................7
   6.3. Registration of the 'audio/raptorfec' Media Type ...........8
        6.3.1. Media Type Definition ...............................8
   6.4. Registration of the 'text/raptorfec' Media Type ...........10
        6.4.1. Media Type Definition ..............................10
7. Mapping to the Session Description Protocol (SDP) ..............12
8. Offer/Answer Considerations ....................................12
9. Declarative SDP Considerations .................................13
10. Repair Flow Generation and Recovery Procedures ................13
   10.1. Overview .................................................13
   10.2. Repair Packet Construction ...............................14
   10.3. Usage of RTCP ............................................14
   10.4. Source Packet Reconstruction .............................14
11. Session Description Protocol (SDP) Example ....................14
12. IANA Considerations ...........................................15
13. Security Considerations .......................................15
14. References ....................................................16
   14.1. Normative References .....................................16
   14.2. Informative References ...................................17

1. Introduction ✨

So the FEC Framework [RFC6363] is the general setup for using Forward Error Correction with all sorts of packet flows, including flows over UDP and RTP [RFC3550]. 🎀 FEC works by generating redundant data packets (the "repair data") that can be sent separately from the original flow. Then, at the receiver, the original flow can be rebuilt as long as a sufficient set of redundant packets, and possibly some original packets, showed up. 💖

The FEC Framework keeps application protocols and FEC codes independent of each other, which is iconic. 👑 A particular FEC code gets plugged in through a FEC Scheme, and that scheme can then be used with any application protocol that's compliant with the framework.

Repair data flows can go straight over a transport protocol like UDP, or they can be wrapped inside specialized multimedia transports like RTP. 🦋

This document defines the RTP payload format for the Raptor FEC Schemes defined in [RFC6681]. 🌸

2. Conventions, Definitions, and Acronyms 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🫶

3. Media Format Background 🌈

Okay, the Raptor and RaptorQ codes are efficient block-based fountain codes. 🌊 That means that from any group of source packets (a "source block"), you can generate as many repair packets as you want. The Raptor and RaptorQ codes also have this property: the original group of source symbols can be recovered with a very high probability from any set of symbols (source and repair) that's only slightly bigger than the original number of source symbols. ✨ The RaptorQ code also has the extra property that recovery is, in many cases, still very likely from a set of symbols (source and repair) that's exactly the same size as the original number of source symbols. Iconic. 🔥

[RFC6681] defines six FEC Schemes for using the Raptor and RaptorQ codes with arbitrary packet flows. 💅 The first two are fully applicable to arbitrary packet flows, using Raptor and RaptorQ respectively. The third and fourth are slightly optimized versions of the first two, for applications with relatively small block sizes. The fifth and sixth are variants of the third and fourth, and they apply to a single source flow that already has some kind of identifiable sequence number. 🧚 Having a sequence number in the source flow allows backwards-compatible operation, because the source flows don't need any changes to apply FEC. In the language of the FEC Framework, that means there's no need for an explicit FEC Source Payload ID, so it isn't included in the packets. 🙈

This document specifies the payload format for RTP repair flows, and it can be used with any of the FEC Schemes defined in [RFC6681]. 💜

4. Payload Format for FEC Repair Packets 🎀

4.1. RTP Header Usage 💖

Header fields SHALL be set according to the rules of [RFC3550]. On top of that, these rules and definitions apply to the RTP headers used with FEC repair packets: 🔥

  • Marker bit: The marker bit SHALL be set to 1 for the last protection RTP packet sent for each source block, and otherwise set to 0. 🏁
  • Payload Type (PT): The payload type codes SHALL be assigned dynamically through non-RTP means. If the Session Description Protocol (SDP) is used for signaling, the rules in Section 7 apply. 🧚
  • Timestamp: This field contains the time at which the packet is transmitted. The time SHOULD be as close as possible to the packet's actual time of transmission. The timestamp value has no use in the actual FEC protection process. However, implementations SHOULD supply a value that can be used for packet-arrival timing or jitter calculations. The timestamp rate is specified using the "rate" media type parameter defined in Section 6. The operator SHALL select a "rate" larger than 1000 Hz to provide sufficient resolution to the Real-Time Transport Control Protocol (RTCP) operations, and the operator SHOULD select the rate that matches the rate of the protected source RTP stream. ⏰
  • Synchronization Source (SSRC): The SSRC values MUST be set according to [RFC3550]. The SSRC value of the RTP repair flow MUST be different from the SSRC value of the protected source flow. 🆔

4.2. Payload Header 🌸

There is no payload header in this payload format. Nothing to see here, bestie! 🙃

4.3. Payload Data 🍓

The procedures and data formats for using Raptor Forward Error Correction in a FECFRAME context are fully defined in [RFC6363] and [RFC6681], and they aren't duplicated here. The procedures in those documents apply when generating the repair data streams carried by the payload formats defined in this document. 🦋

The RTP Payload SHALL contain a Repair FEC Payload ID as defined in [RFC6363] and [RFC6681]. 💅

5. Congestion Control Considerations 🚦

See [RFC6363]. 🫶

6. Media Types 🌈

6.1. Registration of the 'application/raptorfec' Media Type ✨

This RTP payload format is identified using the 'application/raptorfec' media type. That type is registered in accordance with [RFC4855] and uses the template of [RFC4288]. 💜

6.1.1. Media Type Definition

okay bestie, this is the official registration form for application/raptorfec 📝✨ it's basically a checklist of everything you need to set up a Raptor FEC stream 💅

Type name: application

Subtype name: raptorfec

Required parameters:

  • rate: the RTP timestamp (clock) rate 🕰️ it's specified in Hz and the format is an unsigned integer.
  • raptor-scheme-id: the FEC Scheme ID for the specific Raptor FEC Scheme being used, as defined in [RFC6681] 🔑
  • Kmax: the FEC Framework Configuration Information element Maximum Source Block Length (MSBL), as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 📏
  • T: the FEC Framework Configuration Information element for encoding symbol size, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 🧩
  • repair-window: the maximum time that spans the source packets and the corresponding repair packets 🪟 it's specified in microseconds and the format is an unsigned integer.

Optional parameters:

  • P: the FEC Framework Configuration Information element for Payload ID Format, as defined in [RFC6681] 🆔 if it doesn't show up explicitly, the default is 'A' ✨
Encoding considerations: This media type is framed and binary; see
Section 4.8 in [RFC4288]

Security considerations: Please see the security considerations in
[RFC6363].

Interoperability considerations:

Published specification: [RFC6681]

Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video
conferencing.

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information:
Thomas Stockhammer, stockhammer@nomor.de

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550].  Transport
within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research
Change controller: IETF PAYLOAD working group delegated from the
IESG.

6.2. Registration of the 'video/raptorfec' Media Type

now for the video version 🎬🍿 it's identified with the 'video/raptorfec' media type, which is registered in accordance with [RFC4855] and uses the template of [RFC4288] 💜

6.2.1. Media Type Definition

Type name: video

Subtype name: raptorfec

Required parameters:

  • rate: the RTP timestamp (clock) rate 🕰️ it's specified in Hz and the format is an unsigned integer.
  • raptor-scheme-id: the FEC Scheme ID for the specific Raptor FEC Scheme being used, as defined in [RFC6681] 🔑
  • Kmax: the FEC Framework Configuration Information element MSBL, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 📏
  • T: the FEC Framework Configuration Information element for encoding symbol size, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 🧩
  • repair-window: the maximum time that spans the source packets and the corresponding repair packets 🪟 it's specified in microseconds, and the format is an unsigned integer.

Optional parameters:

  • P: the FEC Framework Configuration Information element for Payload ID Format, as defined in [RFC6681] 🆔 if it doesn't show up explicitly, the default is 'A' ✨
Encoding considerations: This media type is framed and binary; see
Section 4.8 in [RFC4288].

Security considerations: Please see the security considerations in
[RFC6363].

Interoperability considerations:

Published specification: [RFC6681]

Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video
conferencing.

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information:
Thomas Stockhammer, stockhammer@nomor.de

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550].  Transport
within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

Change controller: IETF PAYLOAD working group delegated from the
IESG.

6.3. Registration of the 'audio/raptorfec' Media Type

next up is audio 🎧 it's identified with the 'audio/raptorfec' media type, registered in accordance with [RFC4855] using the template of [RFC4288] 🎶

6.3.1. Media Type Definition

Type name: audio

Subtype name: raptorfec

Required parameters:

  • rate: the RTP timestamp (clock) rate 🕰️ it's specified in Hz and the format is an unsigned integer.
  • raptor-scheme-id: the FEC Scheme ID for the specific Raptor FEC Scheme being used, as defined in [RFC6681] 🔑
  • Kmax: the FEC Framework Configuration Information element MSBL, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 📏
  • T: the FEC Framework Configuration Information element for encoding symbol size, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 🧩
  • repair-window: the maximum time that spans the source packets and the corresponding repair packets 🪟 it's specified in microseconds and the format is an unsigned integer.

Optional parameters:

  • P: the FEC Framework Configuration Information element for Payload ID Format, as defined in [RFC6681] 🆔 if it doesn't show up explicitly, the default is 'A' ✨
Encoding considerations: This media type is framed and binary; see
Section 4.8 in [RFC4288].

Security considerations: Please see the security considerations in
[RFC6363].

Interoperability considerations:

Published specification: [RFC6681]

Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video
conferencing.

Additional information:

Magic number(s): <none defined>
File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information:
Thomas Stockhammer, stockhammer@nomor.de

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550].  Transport
within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

Change controller: IETF PAYLOAD working group delegated from the
IESG.

6.4. Registration of the 'text/raptorfec' Media Type

last one in this family is text 📝💖 it's identified with the 'text/raptorfec' media type, registered in accordance with [RFC4855] and using the template of [RFC4288] 🌸

6.4.1. Media Type Definition

Type name: text

Subtype name: raptorfec

Required parameters:

  • rate: the RTP timestamp (clock) rate 🕰️ it's specified in Hz and the format is an unsigned integer.
  • raptor-scheme-id: the FEC Scheme ID for the specific Raptor FEC Scheme being used, as defined in [RFC6681] 🔑
  • Kmax: the FEC Framework Configuration Information element MSBL, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 📏
  • T: the FEC Framework Configuration Information element for encoding symbol size, as defined in [RFC6681], encoded as an unsigned integer. for the specific requirements on this value, refer to [RFC6681] 🧩
  • repair-window: the maximum time that spans the source packets and the corresponding repair packets 🪟 it's specified in microseconds and the format is an unsigned integer.

Optional parameters:

  • P: the FEC Framework Configuration Information element for Payload ID Format, as defined in [RFC6681] 🆔 if it doesn't show up explicitly, the default is 'A' ✨
Encoding considerations: This media type is framed and binary; see
Section 4.8 in [RFC4288].

Security considerations: Please see the security considerations in
[RFC6363].

Interoperability considerations:

Published specification: [RFC6681]

Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video
conferencing.

Additional information:

Magic number(s): <none defined>

File extension(s): <none defined>

Macintosh file type code(s): <none defined>

Person & email address to contact for further information:
Thomas Stockhammer, stockhammer@nomor.de

Intended usage: COMMON

Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [RFC3550].  Transport
within other framing protocols is not defined at this time.

Author: Thomas Stockhammer, Nomor Research.

Change controller: IETF PAYLOAD working group delegated from the
IESG.

7. Mapping to the Session Description Protocol (SDP) 🗺️

okay so, apps that use RTP transport usually reach for the Session Description Protocol (SDP) [RFC4566] to describe their RTP sessions 🎀 the info that sets up the media types in an RTP session has specific mappings onto the fields in an SDP description, and it's honestly so satisfying when it clicks 🫶

heads up though: if an application doesn't use SDP to describe its RTP sessions, it has to define an appropriate mapping for whatever control/description protocol it does use, so it can specify the media types and their parameters 💅

the mapping of the payload format media type defined above and its parameters SHALL be done according to Section 3 of [RFC4855], following the suggestion in there about mapping payload-format-specific parameters into the a=fmtp field ✨

when the RTP payload formats defined in this document are used, the media type parameters defined above MUST use the media types in this document and MUST NOT use those specified in [RFC6364]. no mixing up the media types, bestie 🙅‍♀️💜

8. Offer/Answer Considerations ✨

Okay bestie, so when you're offering Raptor FEC over RTP using SDP in an Offer/Answer model [RFC3264], here's the tea 🫶:

  • Each combination of the Kmax and T parameters produces different FEC data and is not compatible with any other combination. A sender application MAY desire to provide multiple offers with different sets of Kmax and T values, which is possible as long as the parameter values are valid. The receiver SHOULD normally choose the offer with the largest value of the product of Kmax and T that it supports. 🔥
  • The size of the repair window is related to the maximum delay between the transmission of a source packet and the associated repair packet. This directly impacts the buffering requirement on the receiver side, and the receiver must consider this when choosing an offer. 🧚
  • When the P parameter is not present, the receiver MUST use FEC Payload ID Format A. In an answer that selects an offer in which the P parameter was omitted, the P parameter MUST either be omitted, or included with value "A". 💅

9. Declarative SDP Considerations 🌸

In declarative usage, like SDP in the Real-Time Streaming Protocol (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) [RFC2974], these are the vibes to match:

  • The payload format configuration parameters are all declarative, and a participant MUST use the configuration that is provided for the session.
  • More than one configuration MAY be provided (if desired) by declaring multiple RTP payload types. In this case, the receivers should choose the repair session that is best for them. 💜

10. Repair Flow Generation and Recovery Procedures 🦋

10.1. Overview

Okay so this document only specifies repair flow construction when the repair packets are delivered with RTP 🎀. Source packet construction is covered in [RFC6681]. This section gives you the overview on how to generate a repair flow, including the repair packets, and how to rebuild missing source packets from a set of available source and repair packets. The detailed algorithms for generating Raptor and RaptorQ symbols are in [RFC5053] and [RFC6330], respectively.

As per the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes, among other things, the identification of the repair flow(s) and the source flow(s). Methods to convey FEC Framework Configuration Information are provided in [FEC-SIG]. The reader is specifically referred to the SDP elements document [RFC6364], which describes using the 'SDP' encoding format as an example encoding format for FEC Framework Configuration Information. 📜

For the generation of a repair flow:

  • repair packets SHALL be constructed according to Section 10.2, and
  • RTCP SHALL be used according to Section 10.3.

For the reconstruction of a source packet of a source RTP session at the receiver, based on the availability of a source RTP session and a repair RTP session, the procedures in Section 10.4 may be used. ✨

10.2. Repair Packet Construction

The construction of the repair packet is fully specified in Section 4. Honestly the main character of this whole thing 👑. A repair packet is built by concatenating:

  • an RTP header as specified in Section 4.1, and
  • payload data as defined in Section 4.3.

Repair Packet Construction may make use of the Sender Operation for RTP repair flows as specified in see [RFC6363], Section 4.2. 🍓

10.3. Usage of RTCP

RTCP SHALL be used according to [RFC3550]. If the repair RTP session is sent in a separate RTP session, the two sessions MUST be associated using RTCP CNAME (Canonical Name). 🫶

10.4. Source Packet Reconstruction

Source Packet Reconstruction may make use of the receiver operation for the case of RTP repair flows as specified in [RFC6363], Section 4.3. Depending on the FEC Scheme (using the ones defined in [RFC6681]), the appropriate source blocks are formed. If enough data has been received to decode any or all of the missing source payloads in the source block, the respective FEC decoding procedures are applied. 🔥

If the FEC Scheme uses Raptor codes as defined in [RFC5053], then the Example FEC Decoder, as specified in [RFC5053], Section 5.5, may be used.

If the FEC Scheme uses RaptorQ codes as defined in [RFC6330], then the Example FEC Decoder, as specified in [RFC6330], Section 5.4, may be used. 💖

11. Session Description Protocol (SDP) Example 🧚

This section gives an SDP [RFC4566] example, and it's giving very "watch it in action" energy 🎬. Picture one source video stream (mid:S1) and one FEC repair stream (mid:R1). The 'group' attribute and the FEC grouping semantics defined in [RFC5888] and [RFC5956], respectively, are used to link the source and repair flows together. We make one FEC group with the "a=group:FEC S1 R1" line. The source and repair streams go to the same port on different multicast groups, and the repair window is set to 200 ms.

v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor RTP FEC Example
t=0 0
a=group:FEC-FR S1 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=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.2/127
a=rtpmap:110 raptorfec/90000
a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128;
        P=A; repair-window=200000
a=mid:R1

12. IANA Considerations 🌈

IANA has registered application/raptorfec as specified in Section 6.1.1, video/raptorfec as specified in Section 6.2.1, audio/raptorfec as specified in Section 6.3.1, and text/raptorfec as specified in Section 6.4.1. The media type has also been added to the IANA registry for "RTP Payload Format media types" (http://www.iana.org/assignments/rtp-parameters). 🎀

13. Security Considerations 🔐

Okay, serious moment incoming 😭. Read this part carefully, bestie.

Security Considerations related to the use of the FEC Framework are addressed in [RFC6363]. These considerations apply in full to users of the RTP payload formats defined in this document, since these are defined in terms of the FEC Framework.

No further security considerations related specifically to the Raptor FEC Schemes defined in [RFC6681] have been identified.

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encrypting the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system can also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session.

Note that the appropriate mechanism to provide security to RTP and payloads following this memo MAY vary. It depends on the application, transport, and signaling protocol employed. Therefore, a single mechanism is not sufficient. Although, if suitable, using the Secure Real-Time Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP). Other alternatives exist. 🛡️

14. References 📚

14.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, July 2003.

[RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
           Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4855]  Casner, S., "Media Type Registration of RTP Payload
           Formats", RFC 4855, February 2007.

[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.

[RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, July 2006.

[RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
           with Session Description Protocol (SDP)", RFC 3264, June
           2002.

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, March 2004.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, December 2005.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5053]  Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
           "Raptor Forward Error Correction Scheme for Object
           Delivery", RFC 5053, October 2007.

[RFC6330]  Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T.,
           and L. Minder, "RaptorQ Forward Error Correction Scheme
           for Object Delivery", RFC 6330, August 2011.

14.2. Informative References

[RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
           Streaming Protocol (RTSP)", RFC 2326, April 1998.

[RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
           Announcement Protocol", RFC 2974, October 2000.

[RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
           Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

[RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
           the Session Description Protocol", RFC 5956, September
           2010.

[FEC-SIG]  Asati, R., "Methods to convey FEC Framework Configuration
           Information", Work in Progress, February 2012.

Authors' Addresses 🎀

Mark Watson
Netflix
100 Winchester Circle
Los Gatos, CA 95032
United States

EMail: watsonm@netflix.com


Thomas Stockhammer
Nomor Research
Brecherspitzstrasse 8
Munich 81541
Germany

EMail: stockhammer@nomor.de


Michael Luby
Qualcomm Research Berkeley
2030 Addison Street
Berkeley, CA 94704
United States

EMail: luby@qualcomm.com
📦 where this page comes from