RFC 6695

RFC 6695 🎀 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information

Okay bestie, let's start with the basics 💅 This is RFC 6695, written by R. Asati from Cisco Systems, and it's dated August 2012. It's Informational, so it's published for information and isn't an Internet Standards Track spec 🌸 The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

Okay so the FEC Framework document (RFC 6363) is where the FEC Framework Configuration Information gets defined, and that info is needed for the FEC Framework to work at all 🫶 This doc is about how signaling protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. can be used to figure out that configuration and pass it between sender(s) and receiver(s) 🦋

Plot twist: this doc doesn't define any new signaling protocol 🙈

Status of This Memo

Not an Internet Standards Track spec, just published for info 🌈

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💜

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6695 ✨

Copyright Notice

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 in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🍓

Table of Contents

1. Introduction ....................................................2
2. Specification Language ..........................................3
3. Terminology/Abbreviations .......................................3
4. FEC Framework Configuration Information .........................4
   4.1. Encoding Format ............................................5
5. Signaling Protocol Usage ........................................6
   5.1. Signaling Protocol for Multicasting ........................7
        5.1.1. Sender Procedure ....................................9
        5.1.2. Receiver Procedure .................................11
   5.2. Signaling Protocol for Unicasting .........................12
        5.2.1. SIP ................................................12
        5.2.2. RTSP ...............................................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgments ................................................14
9. References .....................................................14
   9.1. Normative References ......................................14
   9.2. Informative References ....................................15

1. Introduction ✨

Okay so the FEC Framework doc [RFC6363] is the one that defines the FEC Framework Configuration Information. That info controls how the FEC Framework runs for any FEC scheme, and it must be available at both the sender and the receiver(s) 💅

This doc shows how signaling protocols like the Session Announcement Protocol (SAP) [RFC2974], the Session Initiation Protocol (SIP) [RFC3261], the Real Time Streaming Protocol (RTSP) [RFC2326], etc. could be used by the FEC scheme (and/or the Content Delivery Protocol (CDP)) to pass the configuration info between the sender and receiver(s). The config info may be encoded in any compatible format, like the Session Description Protocol (SDP) [RFC4566], XML, etc. Heads up though, this doc uses SDP encoding quite a lot 🦋

Note that this document doesn't define any new signaling protocol. It just gives examples of how existing protocols should be used. Also, the list of unicast signaling protocols isn't meant to be complete 🫶

This doc doesn't describe any FEC-Scheme-Specific Information (FSSI), like how source blocks get built, or any sender- or receiver-side behavior for a particular FEC scheme, like whether the receiver uses one or more repair flows that it receives. Those FEC scheme details should live in separate document(s). This doc also doesn't mandate a particular encoding format for the config info 🌸

Here's the layout: Section 3 covers the terms, Section 4 covers the FEC Framework Configuration Information, Section 5 covers how to use signaling protocols for multicast and unicast apps, and Section 6 talks about security considerations 🧚

2. Specification Language 💜

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. Terminology/Abbreviations 🌈

This doc uses the terms and abbreviations from the FEC Framework doc [RFC6363], and it also defines these extra terms:

• Media Sender - the node that gives the original media flow(s) to the 'FEC Sender' 🎀
• Media Receiver - the node that does the media decoding 🍓
• FEC Sender - the node that does the FEC encoding on the original media flow(s) to make the FEC repair flow(s) ✨
• FEC Receiver - the node that does the FEC decoding when needed and hands the original media flow(s) to the Media Receiver 💖
• Sender - same as FEC Sender
• Receiver - same as FEC Receiver
• (Media) Flow - a single media instance, i.e., an audio stream or a video stream 🎶

This doc deliberately calls the 'FEC Sender' and 'FEC Receiver' the 'Sender' and 'Receiver', respectively 🫶

4. FEC Framework Configuration Information 👑

The FEC Framework [RFC6363] sets a minimum set of info that gets passed between the sender and receiver(s) so an FEC scheme can run properly. This is called "FEC Framework Configuration Information", and it's the stuff the FEC Framework needs in order to apply FEC protection to the transport flows 💅

One FEC Framework instance protects all the packets of a specified set of source packet flows, using one or more packet flows made of repair packets 🦋 As per Section 5.5 of the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes these items for each FEC Framework instance:

1. Identification of the repair flow(s)
2. Identification of source flow(s)
3. Identification of FEC scheme
4. Length of Explicit Source FEC Payload ID
5. FSSI

FSSI is basically an opaque container for FEC-scheme-specific config info, like buffer size, decoding wait-time, etc. For more, go check the FEC Framework doc [RFC6363] 🧚

Using the signaling protocols in this doc requires that the application layer responsible for the FEC Framework instance provides a value for each of the config parameters listed above, encoded in the chosen encoding format. If the complete info isn't received, the signaling protocol module must return an error for Operations, Administration, and Maintenance (OAM) purposes, and it may optionally pass that error up to the application layer 😭 For more illustration, see Figure 1 of the FEC Framework document [RFC6363].

This doc doesn't assume that the 'FEC Sender' and 'Media Sender' functions live on the same device, though they might. Same deal for the 'FEC Receiver' and 'Media Receiver' 🌸 There may also be more than one Media Sender 🍓

4.1. Encoding Format 🎀

The FEC Framework Configuration Information (listed above in Section 4) may be encoded in any format, like SDP, XML, etc., whatever a particular FEC Framework instance chooses or prefers. Picking the encoding format is independent of the signaling protocol and is out of scope for this doc 💜

Any encoding format picked for a particular FEC Framework instance must be known to the signaling protocol. The signaling protocol needs a way (e.g., a field such as Payload Type) to say which encoding format is used, so the payload (the config info) can be parsed correctly at the receiver according to that format's rules. Also, the encoding format isn't a negotiated parameter. It's a property of a particular FEC Framework instance and/or its implementation 🔥

The encoding format for each FEC Framework config parameter must be defined as a sequence of octets that can be embedded in the payload of the signaling protocol message(s). The length of the encoding format must either be fixed or be derived by examining the encoded octets themselves. For example, the first octets might include some kind of length indication 🦋

No matter which encoding formats an FEC scheme supports, each instance of the FEC Framework must use a single encoding format to describe all of the config info for that instance. The signaling protocol specified in this doc should not validate the encoded info, though it may validate the syntax or length of that info 🌈

If you want an example of the 'SDP' encoding format for the FEC Framework Configuration Information, check the SDP elements document [RFC6364], which walks through it 💖

in this part... wait. Before I start, let me be clear about what this part is: a continuation of an RFC rewrite, starting right where section 4.1 left off. No greeting, no recap. Here we go 🎀

5. Signaling Protocol Usage ✨

okay so bestie, the FEC Framework [RFC6363] needs certain FEC Framework Configuration Information to be available to BOTH the sender and the receiver(s) 💖 this info is almost always put together at the sender (or on the sender's behalf) and then somehow gets to the receiver(s) 🦋 you could totally set it up statically on everyone, but that's giving chaos 😭 because (a) you'd have to know every single receiver ahead of time 🙈, (b) you'd need the time and means to configure each receiver and each sender by hand, and (c) it makes misconfiguration way more likely 💀 so a dynamic method (aka a signaling protocol) to pass the configuration info between the sender and one or more receivers is the move 💅 🌸

so here's the thing: the stream could be unicast (think Video on Demand, VoD 🍿) or multicast (broadcast or IPTV 📺), and a single receiver versus a whole crowd of receivers needs different delivery 💜 so we need TWO types of signaling protocols 👑 one to deliver the configuration info to many receivers via multicasting (see Section 5.1), and one to deliver it to one and only one receiver via unicasting (see Section 5.2) 🫶

Figure 1 is the vibe check 🔥 the FEC Sender and FEC Receiver (which may or may not be the Media Sender and Media Receiver, respectively) are laid out so FEC_Sender1 is serving FEC_Receiver11, FEC_Receiver12, and FEC_Receiver13 over the multicast signaling protocol 🌈, while FEC_Sender2 is serving only FEC_Receiver2 over the unicast signaling protocol 🧚

FEC_Sender2---------|         |--------FEC_Receiver2
                    |         |
FEC_Sender1-------IP/MPLS network
                            |-----------FEC_Receiver11
                            |-----------FEC_Receiver12
                            |-----------FEC_Receiver13

Figure 1. Topology Using Sender and Receiver 🍓

the rest of the doc keeps using 'Sender' and 'Receiver' to mean 'FEC Sender' and 'FEC Receiver' 💜 no confusion, we're consistent 💅

5.1. Signaling Protocol for Multicasting 📡

this spec describes using SAP version 2 [RFC2974] as the signaling protocol to multicast the configuration info from one sender to many receivers 🦋 the apparent advantage is that the server doesn't need to keep any state for any receiver using SAP 🙌

SAP messages are carried over UDP over IP with destination UDP port 9875, as described in [RFC2974], and a source UDP port of any available number. The SAP message(s) MUST contain an authentication header using Pretty Good Privacy (PGP) authentication. 🔐

at the high level 🌸, a sender (acting as the SAP announcer) signals the FEC Framework Configuration Information for each FEC Framework instance available at the sender, using the SAP message(s) ✨ the config info, encoded in a suitable format as per Section 4.1, rides along in the payload of the SAP message(s) 🎀 a receiver (acting as the SAP listener) listens on a well-known UDP port and at least one well-known multicast group IP address (as explained in Section 5.1.1) 👀 this lets the receiver get the SAP message(s) and obtain the FEC Framework Configuration Information for each FEC Framework instance 💖

so once the receiver has the config info, it becomes aware of the available FEC protection options, the corresponding multicast trees (S,G or *,G addresses), and more 🧠 the receiver may then subscribe to one or more multicast trees to receive the FEC streams using out-of-band multicasting techniques such as PIM [RFC4601] 🫶 BUT that part is outside the scope of this document, so we're not going there today 🙅‍♀️

Figure 2 (reprinted from [RFC2974]) is the SAP packet format 📦

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | V=1 |A|R|T|E|C|   auth len    |         msg id hash           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                originating source (32 or 128 bits)            :
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    optional authentication data               |
 :                              ....                             :
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 |                      optional payload type                    |
 +                                         +-+- - - - - - - - - -+
 |                                         |0|                   |
 + - - - - - - - - - - - - - - - - - - - - +-+                   |
 |                                                               |
 :                            payload                            :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. SAP Message Format 🌈

so the 'Payload' field is what carries the FEC Framework Configuration Information 💜 and the optional 'Payload Type' field is a MIME content type specifier that describes the encoding format used for the payload 🧚 (the spec has explanations for each field in [RFC2974], but these two are the fun ones to talk about 💅)

For example, the 'Payload Type' field may be application/sdp if the FEC Framework Configuration Information is encoded in SDP format and carried in the SAP payload. Similarly, it would be application/xml if the FEC Framework Configuration Information were encoded in XML format. 🎀

last bit 🫶: Section 5.1.1 covers the sender procedure, and Section 5.1.2 covers the receiver procedure for config signaling using [RFC2974] ✨ more coming in the next part, bestie 💖

5.1.1. Sender Procedure 📮✨

okay bestie, so the sender is the one who announces the FEC Framework Configuration Information 📣 for each FEC Framework instance, and it does that in a periodic SAP announcement message [RFC2974] 💌. The SAP announcement message goes to a well-known multicast IP address and UDP port, as specified in [RFC2974] 🎀. The announcement is multicast with the same scope as the session being announced 🌸.

The SAP module at the sender grabs the FEC Framework Configuration Information for each instance from the 'FEC Framework' module and tucks it into the SAP payload 🧚. A single SAP (announcement) message must carry the FEC Framework Configuration Information for a single FEC Framework instance 💅. After that, the SAP message gets sent over UDP over IP 🦋.

🫶 Note: While it is possible to aggregate multiple SAP (announcement) messages in a single UDP datagram as long as the resulting UDP datagram length is less than the IP MTU of the outgoing interface, this specification does not recommend it, since there is no length field in the SAP header to identify a SAP message boundary. Hence, this specification recommends that a single SAP announcement message be sent in a UDP datagram.

The IP packet carrying the SAP message must be sent to a destination IP address that matches the scope you picked, and there are three options 🍓:

• 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 is selected for the FEC stream), or
• ff0x:0:0:0:0:0:2:7ffe (if IPv6 multicasting is selected for the FEC stream, where x is the 4-bit scope value), or
• the highest multicast address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0-239.255.255.255 is selected for the FEC stream)

As defined in [RFC2974], the IP packet carrying a SAP message must use destination UDP port 9875 and a source UDP port of any available number 🔢. The default IP Time to Live (TTL) value (or Hop Limit value) should be 255 at the sender, though the sender implementation may allow it to be any other value to implicitly create the multicast boundary for SAP announcements 🚧. The IP Differentiated Services Code Point (DSCP) field may be set to any value that indicates a desired QoS treatment in the IP network 💜.

The IP packet carrying the SAP message must be sent with a source IP address that is reachable by the receiver 📍. The sender may assign the same IP address in the 'originating source' field of the SAP message as the one used in the source IP address of the IP packet 🌈.

Furthermore, the FEC Framework Configuration Information must not include any of the reserved multicast group IP addresses for the FEC streams (i.e., source or repair flows), though it may use the same IP address as the 'originating source' address to identify the FEC streams (i.e., source or repair flows). Please refer to IANA assignments for multicast addresses 🙈.

The sender must periodically send the 'SAP announcement' message to make sure that the receiver doesn't purge the cached entry or entries from the database, and doesn't trigger the deletion of the FEC Framework Configuration Information ⏰.

While the time interval between repetitions of an announcement can be calculated using the very sophisticated but complex method explained in [RFC2974], this document recommends a simpler method 🧠. In this simpler method, the user specifies the time interval in the range of 1-200 seconds, with a suggested default value of 60 seconds ✨. The 'time interval' may be signaled in the SAP message payload, e.g., within the FEC Framework Configuration Information 📦.

💡 Note: SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the simpler method requires that the time interval be included in the FEC Framework Configuration Information if the default time interval (60 seconds) for SAP message repetitions is not used. For example, the usage of the 'r=' (repeat time) field in SDP may convey the time interval value if the SDP encoding format is used.

The time interval must be chosen to ensure that SAP announcement messages are sent out before the corresponding multicast routing entry, e.g., (S,G) or (*,G) (corresponding to the SAP multicast tree(s)) on the router(s) times out. (It is worth noting that the default timeout period for the multicast routing entry is 210 seconds, per the PIM specification [RFC4601], though the timeout period may be set to another value as allowed by the router implementation 🕰️.)

🌸 Note: A SAP implementation may also support the complex method for determining the SAP announcement time interval and provide the option to select it.

The sender may choose to delete the announced FEC Framework Configuration Information, as defined in Section 4 of [RFC2974] 🗑️. Explicit deletion is useful if the sender no longer wants to send any more FEC streams 👋.

If the sender needs to modify the announced FEC Framework Configuration Information for one or more FEC instances, then the sender must send a new announcement message with a different 'Message Identifier Hash' value, following the rules described in Section 5 of RFC 2974 [RFC2974] 🔄. Such an announcement message should be sent immediately (without having to wait for the time interval) so that the modifications reach the receiver as soon as possible ⚡. The sender must also send the SAP deletion message to delete the previous SAP announcement message (i.e., the one with the previous 'Message Identifier Hash' value) 🧹.

5.1.2. Receiver Procedure 👂💖

The receiver must listen on UDP port 9875 for packets arriving with an IP destination address of either 224.2.127.254 (if an IPv4 global scope session is used for the FEC stream), ff0x:0:0:0:0:0:2:7ffe (if IPv6 is selected, where x is the 4-bit scope value), or the highest IP address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0-239.255.255.255 is selected for the FEC stream) 👀. These IP addresses are mandated for SAP usage by RFC 2974 [RFC2974] 📜.

The receiver, upon receiving a SAP announcement message, creates an entry in a local database if one doesn't already exist, and passes the FEC Framework Configuration Information from the SAP Payload field to the 'FEC Framework' module 🗄️. Each entry also maintains a timeout value, which is (re)set to five times the time interval value 🕔. That time interval value is either the default of 60 seconds or the value signaled by the sender ✨.

🎀 Note: SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the time interval should be included in the FEC Framework Configuration Information -- for example, the usage of the 'r=' (repeat time) field in SDP to convey the time interval value if the SDP encoding format is used.

The timeout value associated with each entry is reset when the corresponding announcement (please see Section 5 of [RFC2974]) is received 🔁. If the timeout value for any entry reaches zero, then that entry must be deleted from the database, as described in Section 4 of [RFC2974] ⌛. The receiver, upon receiving a SAP delete message, must delete the matching SAP entry in its database, as described in Section 4 of [RFC2974] 🧹.

The deletion of a SAP entry must result in the receiver no longer using the relevant FEC Framework Configuration Information for the corresponding instance, and no longer subscribing to any related FEC streams 🚫.

5.2. Signaling Protocol for Unicasting 💌🦋

This document describes leveraging any signaling protocol that is already used by the unicast application to exchange the FEC Framework Configuration Information between two nodes 🤝.

For example, a multimedia (VoD) client may send a request via unicasting for a particular content to the multimedia (VoD) server, and the server may offer various options such as encodings, bitrates, transport, etc. for that content 🎬. The client selects the suitable options and answers the server, which paves the way for the content to be unicast on the chosen transport from the server to the client 🍿. This offer/answer signaling, described in [RFC3264], is commonly used by many application protocols, such as SIP, RTSP, etc. 💅.

Two nodes that want unicast communication almost always rely on an application to first exchange the application-related parameters via the signaling protocol. That makes it logical to enhance such signaling protocol(s) to (a) convey the desire for the FEC protection and (b) subsequently also exchange FEC parameters, i.e., the FEC Framework Configuration Information 🧩. This enables the node acting as the offerer to offer 'FEC Framework Configuration Information' for each available FEC instance, and the node acting as the answerer to convey the chosen FEC Framework instance(s) to the offerer 🎯. The usage of the FEC Framework instance is explained in the FEC Framework document [RFC6363] 📖.

While enhancing an application's signaling protocol to exchange FEC parameters is one method (briefly explained above), an alternative method would be to have a unicast-based generic protocol that two nodes could use, independent of the application's signaling protocol 🌈. The latter is not covered by this document, of course 🙃.

The remainder of this section provides example signaling protocols and explains how they can be used to exchange the FEC Framework Configuration Information ✨.

5.2.1. SIP 📞💜

SIP [RFC3261] is an application-level signaling protocol used to create, modify, and terminate multimedia sessions with one or more participants 🎥. SIP also lets participants discover one another and agree on a characterization of a multimedia session they would like to share 🤩. SIP runs on either TCP, UDP, or Stream Control Transmission Protocol (SCTP) transport, and uses SDP as the encoding format to describe multimedia session attributes 🧁.

SIP already uses an offer/answer model with SDP, as described in [RFC3264], to exchange information between two nodes and establish unicast sessions between them 💞. This document extends the usage of this model for exchanging the FEC Framework Configuration Information (described in Section 4) 🦄. Any SDP-specific enhancements to accommodate the FEC Framework are covered in the SDP elements specification [RFC6364] 👑.

5.2.2. RTSP 🎬

okay so RTSP [RFC2326] is an application-level signaling protocol for controlling the delivery of data with real-time properties 🎀. It gives you an extensible framework for controlled, on-demand delivery of real-time data like audio and video 🎶. RTSP runs on either TCP or UDP transports 🚀.

RTSP already lets you extend an existing method with new parameters ✨. This specification defines the FEC-protection-needed option tag (see Section 7 for IANA Considerations) 🏷️. It also says to put that tag in the Require (or Proxy-Require) header of SETUP (method) request messages, so you can ask for FEC protection on the data 🛡️.

The node that gets that request either replies with a 200 OK message that includes offers, meaning the available FEC options (for example, FEC Framework Configuration Information for each instance) 💌, or with a 551 Option not supported message 🙅‍♀️. Here's a sample of how the messages go back and forth:

   Node1->Node2:  SETUP < ... > RTSP/1.0
                  CSeq: 1
                  Transport: <omitted for simplicity>
                  Require: FEC-protection-needed

   Node2->Node1:  RTSP/1.0 200 OK
                  CSeq: 1
                  Transport: <omitted for simplicity>

After that, the requesting node (Node1) can send a new SETUP message to tell Node2 which FEC protection it picked, and then carry on with regular RTSP messaging 🧚.

Also, if Node1 gets a 551 Option not supported response from Node2, Node1 may just send the SETUP message without the Require header 🥺.

---

6. Security Considerations 🔐

bestie, this one is serious 🫶. This document recommends that SAP message(s) be authenticated so the sender can be authenticated, as described in Section 5.1 🕵️‍♀️. Please do not skip this step 💀.

There are no additional security considerations beyond the ones already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and [RFC3261] for SIP 📚.

---

7. IANA Considerations 🗂️

IANA has registered a new RTSP option tag, listed below 🌸. It's in the RTSP/1.0 Option Tags table of the "Real Time Streaming Protocol (RTSP)/1.0 Parameters" registry, which is available from http://www.iana.org/ 🌐. The registration follows Section 3.8.1 of [RFC2326] ✅.

• Name of option-tag: FEC-protection-needed
• Description: See Section 5.2.2
• Change Control: IETF

---

8. Acknowledgments 🙌

Thanks to Colin Perkins for pointing out the issue with the time interval for the SAP messages 💜. Also thanks to Vincent Roca, Ali Begen, Mark Watson, Ulas Kozat, and David Harrington for greatly improving this document 🥹✨.

---

9. References 📖

9.1. Normative References

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

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

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

9.2. Informative References

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

[RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.

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

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

[RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
            "Protocol Independent Multicast - Sparse Mode (PIM-SM):
            Protocol Specification (Revised)", RFC 4601, August 2006.

---

Author's Address 💌

Rajiv Asati
Cisco Systems
7025-6 Kit Creek Rd.
RTP, NC  27709-4987

EMail: rajiva@cisco.com