RFC 4587

RTP Payload Format for H.261 Video Streams 🦋

Okay bestie, this is RFC 4587 💖 It's from the Network Working Group, written by R. Even at Polycom, and dated August 2006. It's a Standards Track doc, and it obsoletes RFC 2032 (so that older one is out 💅). It also updates the "video/h261" media type that got registered back in RFC 3555, which we'll get to in the Introduction.

Status of This Memo

This doc is an Internet standards track protocol for the whole Internet community, and it's asking for discussion and suggestions for improvements 🌸 If you want to know where this protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed with no limits, so share away 🫶

Copyright Notice

Copyright (C) The Internet Society (2006).

Abstract

This memo is all about how to packetize an H.261 video stream so it can ride over RTP (the Real-time Transport Protocol), no matter which underlying protocols carry that RTP 🚀

It also breaks down the syntax and semantics of the Session Description Protocol (SDP) parameters you need to support the H.261 video codec 🎀 And there's a media type registration included for this payload format, so it's all official ✨

Last but not least, this specification obsoletes RFC 2032 👑

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Structure of the Packet Stream ..................................3
      3.1. Overview of the ITU-T Recommendation H.261 .................3
      3.2. Considerations for Packetization ...........................4
   4. Specification of the Packetization Scheme .......................5
      4.1. Usage of RTP ...............................................5
      4.2. Recommendations for Operation with Hardware Codecs .........8
   5. Packet Loss Issues ..............................................9
   6. IANA Considerations ............................................10
      6.1. Media Type Registrations ..................................10
           6.1.1. Registration of MIME Media Type video/H261 .........10
      6.2. SDP Parameters ............................................12
           6.2.1. Usage with the SDP Offer Answer Model ..............12
   7. Backward Compatibility to RFC 2032 .............................13
      7.1. Optional H.261-Specific Control Packets ...................13
      7.2. New SDP Optional Parameters ...............................13
   8. Security Considerations ........................................14
   9. Acknowledgements ...............................................14
   10. Changes from RFC 2032 .........................................14
   11. References ....................................................15
      11.1. Normative References .....................................15
      11.2. Informative References ...................................15

1. Introduction 🎬

So, ITU-T Recommendation H.261 [H261] is the encoding that ITU-T-compliant video-conference codecs use 📹 It was originally designed for fixed-data-rate ISDN (Integrated Services Digital Network) circuits, but experiments [INRIA], [MICE] showed it works over packet-switched networks too, like the Internet 🌈

The whole point of this memo is to define the RTP payload format for wrapping H.261 video streams up in RTP [RFC3550] ✨

Also! This document obsoletes RFC 2032 and updates the "video/h261" media type that got registered in RFC 3555 💅

2. Terminology 📖

Okay, so these ten key words, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", mean what RFC 2119 [RFC2119] says they mean 🧚 They set the requirement levels for compliant RTP implementations, so they're kind of a big deal 🔥

3. Structure of the Packet Stream 🧩

3.1. Overview of the ITU-T Recommendation H.261

H.261 coding is organized like a hierarchy of groupings 🍓 A video stream is a sequence of images (called frames), and each frame is organized into a set of Groups of Blocks (GOB). Quick heads-up: H.261 calls these "pictures," but this document calls them "frames," so don't get confused 🙈

Each GOB holds a set of 3 lines of 11 macro blocks (MB). Each MB covers a group of 16x16 pixels. The luminance info is given for 4 blocks of 8x8 pixels, and the chrominance info is two "red" and "blue" color difference components at a resolution of only 8x8 pixels. These components, and the codes that represent their sampled values, are defined in ITU-R Recommendation 601 [BT601] 🎨

Here's how the grouping gets used to specify info at each level of the hierarchy:

• At the frame level, you specify stuff like the delay from the previous frame, the image format, and various indicators 🖼️
• At the GOB level, you specify the GOB number and the default quantifier that the MBs will use 🔢
• At the MB level, you specify which blocks are present and which didn't change, and, optionally, a quantifier and motion vectors 🏃‍♀️

Blocks that have changed get encoded by computing the discrete cosine transform (DCT) of their coefficients. Those then get quantized and Huffman encoded (Variable Length Codes) 🧮

Now, the H.261 Huffman encoding has a special "GOB start" pattern. It's a 16-bit word, 0000 0000 0000 0001. This pattern shows up at the beginning of each GOB header (and at the beginning of each frame header too). It marks the separation between two GOBs, and it's actually used as an indicator that the current GOB has ended 🛑

The encoding also has a stuffing pattern made of seven zero bits followed by four bits with a value of one. That stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator 🫧

3.2. Considerations for Packetization

H.261 codecs that were designed for ISDN circuits produce a bit stream made of several levels of encoding, specified by H.261 and its companion recommendations. The bits that come out of the Huffman encoding get arranged into 512-bit frames. Each frame has 2 bits of synchronization, 492 bits of data, and 18 bits of error correcting code 🛡️ Then those 512-bit frames get interlaced with an audio stream and sent over px 64 kbps circuits, following H.221 [H221] 📞

For transmitting over the Internet, though, we're going to look directly at the output of the Huffman encoding. All the bits that the Huffman encoding stage produces will be included in the packet 📦 We are not going to carry the 512-bit frames, because protection against bit errors can be handled by other means. We also won't try to multiplex audio and video into the same packets, because UDP and RTP already give us a way better way to do multiplexing 💜

Here's the catch though: sending the Huffman output straight over an unreliable stream of UDP datagrams would have poor error resistance 😭 The hierarchy is the problem. You need the info in the frame header to decode the GOBs, and you need the info in the GOB header to decode the MBs. Without precautions, that means you'd have to receive every packet that carries an image just to decode its components properly 🥲

If every image could fit in a single packet, this wouldn't be an issue. But a video image, or even one GOB by itself, can sometimes be too big to fit in one packet 📏

So the MB is taken as the unit of fragmentation ✂️ Packets must start and end on an MB boundary, which means an MB can't be split across multiple packets. Multiple MBs may be carried in a single packet when they fit within the maximal packet size allowed. This practice is recommended, since it reduces the packet send rate and packet overhead 🚀

To let each packet get processed independently (which makes resynchronization way more efficient when packets get lost), some state information from the frame header and GOB header gets carried with each packet. That's so the MBs in that packet can be decoded 🧠 This state info includes:

• the GOB number in effect at the start of the packet,
• the macroblock address predictor (basically, the last macroblock address (MBA) encoded in the previous packet),
• the quantizer value in effect prior to the start of this packet (GQUANT, MQUANT, or zero in the case of a beginning of GOB), and
• the reference motion vector data (MVD) for computing the true MVDs contained within this packet 📊

Important! The bit stream cannot be fragmented between a GOB header and MB 1 of that GOB 🚫

And finally, since a compressed MB may not fill an integer number of octets, the data header contains two 3-bit integers, SBIT and EBIT. These tell you the number of unused bits in the first and last octets of the H.261 data, respectively 🎯

4. Specification of the Packetization Scheme ✨

4.1. Usage of RTP ✨

okay bestie, every RTP packet starts with a fixed RTP header 💖. The whole story is in RFC 3550 [RFC3550]. These are the fixed header fields that H.261 video streams lean on the hardest 🎀:

• Payload type. Assigning an RTP payload type for this packet format is outside the scope of this document, so it won't be specified here 🌸. The RTP profile for a particular class of applications is expected to assign a payload type for this encoding. If that doesn't happen, then a payload type in the dynamic range shall be chosen ✨.
• Timestamp. The RTP timestamp encodes the sampling instant of the first video image in the RTP data packet 🦋. If a video image takes up more than one packet, the timestamp SHALL be the same on all of those packets. Packets from different video images MUST have a different timestamp, so frames can be told apart by their timestamps 👑. H.261 timestamps run on a 90-kHz clock, and that's a multiple of the natural H.261 frame rate (30000/1001, or about 29.97 Hz) 🧚. So each frame time the clock just goes up by that multiple, which means no inaccuracy when calculating the timestamp 💅. The initial value of the timestamp MUST be random (unpredictable) to make known-plaintext attacks on encryption harder; see RTP [RFC3550] 🙈. If multiple frames are encoded in one packet (say, there are very few changes between two images), the display times for the frames after the first have to be calculated from the timing information in the H.261 frame header 💜. That's required, because the RTP timestamp only gives the display time of the first frame in the packet 😭.
• Marker bit. The marker bit of the RTP header MUST be set to one in the last packet of a video frame; otherwise, it MUST be zero. So there's no need to wait for a following packet (the one with the start code that ends the current frame) to figure out that a new frame should be displayed 🌈.

The H.261 data SHALL follow the RTP header, like this 🦋:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                          RTP header                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          H.261  header                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          H.261 stream ...                     .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The H.261 header is defined as follows 🎀:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |SBIT |EBIT |I|V| GOBN  |   MBAP  |  QUANT  |  HMVD   |  VMVD   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field in the H.261 header means 💅:

Start bit position (SBIT): 3 bits 🍓 Number of most significant bits that should be ignored in the first data octet.

End bit position (EBIT): 3 bits 🍓 Number of least significant bits that should be ignored in the last data octet.

INTRA-frame encoded data (I): 1 bit 🧚 Set to 1 if this stream contains only INTRA-frame coded blocks. Set to 0 if this stream may or may not contain INTRA-frame coded blocks. The meaning of this bit should not be changed during the course of the RTP session.

Motion Vector flag (V): 1 bit 🦋 Set to 0 if motion vectors are not used in this stream. Set to 1 if motion vectors may or may not be used in this stream. The meaning of this bit should not be changed during the course of the session.

GOB number (GOBN): 4 bits 🌸 Encodes the GOB number in effect at the start of the packet. Set to 0 if the packet begins with a GOB header.

Macroblock address predictor (MBAP): 5 bits 👑 Encodes the macroblock address predictor (i.e., the last MBA encoded in the previous packet). This predictor ranges from 0 - 32 (to predict the valid MBAs 1 - 33), but because the bit stream cannot be fragmented between a GOB header and MB 1, the predictor at the start of the packet shall not be 0. Therefore, the range is 1 - 32, which is biased by -1 to fit in 5 bits. For example, if MBAP is 0, the value of the MBA predictor is 1. Set to 0 if the packet begins with a GOB header.

Quantizer (QUANT): 5 bits 💜 Quantizer value (MQUANT or GQUANT) in effect prior to the start of this packet. Set to 0 if the packet begins with a GOB header.

Horizontal motion vector data (HMVD): 5 bits 🌈 Reference horizontal motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not motion compensation (MC). HMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 is forbidden (motion vector fields range from +/-15).

Vertical motion vector data (VMVD): 5 bits ⭐ Reference vertical motion vector data (MVD). Set to 0 if V flag is 0 or if the packet begins with a GOB header, or when the MTYPE of the last MB encoded in the previous packet was not MC. VMVD is encoded as a 2s complement number, and '10000' corresponding to the value -16 SHALL not be used (motion vector fields range from +/-15).

Note that the I and V flags are hint flags; i.e., they can be inferred from the bit stream. They are included to allow decoders to make optimizations that would not be possible if these hints were not provided before the bit stream was decoded. Therefore, these bits cannot change for the duration of the stream. A conforming implementation can always set V=1 and I=0. 🫶

The H.261 stream SHALL be used without BCH error correction and without error correction framing.

---

4.2. Recommendations for Operation with Hardware Codecs 🔥

Packetizers for hardware codecs can trivially figure out GOB boundaries, using the GOB-start pattern included in the H.261 data. (Note that software encoders already know the boundaries.) The cheapest packetization implementation is to packetize at the GOB level all the GOBs that fit in a packet. But when a GOB is too large, the packetizer has to parse it to do MB fragmentation. (Note that only the Huffman encoding must be parsed and that it is not necessary to decompress the stream fully, so this requires relatively little processing; examples of implementations can be found in some public H.261 codecs, such as IVS [IVS] and VIC [VIC].) It is recommended that MB level fragmentation be used when feasible in order to obtain more efficient packetization. Using this fragmentation scheme reduces the output packet rate and therefore reduces the overhead. 💅

At the receiver, the data stream can be depacketized and directed to a hardware codec's input. If the hardware decoder operates at a fixed bit rate, synchronization may be maintained by inserting the stuffing pattern between MBs (i.e., between packets) when the packet arrival rate is slower than the bit rate. ✨

5. Packet Loss Issues 💀

On the Internet, most packet losses are due to network congestion rather than to transmission errors. Using UDP, no mechanism is available at the sender to know whether a packet has been successfully received. It is up to the application (i.e., coder and decoder) to handle the packet loss. Each RTP packet includes a sequence number field that can be used to detect packet loss. 😭

H.261 uses the temporal redundancy of video to perform compression. This differential coding (or INTER-frame coding) is sensitive to packet loss. After a packet loss, parts of the image may remain corrupt until all corresponding MBs have been encoded in INTRA-frame mode (i.e., encoded independently of past frames). There are several ways to mitigate packet loss 🛡️:

1. One way is to use only INTRA-frame encoding and MB-level conditional replenishment. That is, only MBs that change (beyond some threshold) are transmitted.
2. Another way is to adjust the INTRA-frame encoding refreshment rate according to the packet loss observed by the receivers. The H.261 recommendation specifies that an MB be INTRA-frame encoded at least every 132 times it is transmitted. However, the INTRA-frame refreshment rate can be raised in order to speed the recovery when the measured loss rate is significant.
3. The fastest way to repair a corrupted image is to request an INTRA-frame coded image refreshment after a packet loss is detected. One means to accomplish this is for the decoder to send to the coder a list of packets lost. The coder can decide to encode every MB of every GOB of the following video frame in INTRA-frame mode (i.e., full INTRA-frame encoded). If the coder can deduce from the packet sequence numbers which MBs were affected by the loss, it can save bandwidth by sending only those MBs in INTRA-frame mode. This mode is particularly efficient in point-to-point connection or when the number of decoders is low.

The H.261-specific control packets FIR and NACK, as described in RFC 2032, SHALL NOT be used to request image refreshment. Old implementations are encouraged to use the methods described in this section. Image refreshment may be needed due to packet loss or due to application requirements. An example of application requirement may be the change of the speaker in a voice-activated multipoint video switching conference. There are two methods that can be used for requesting image refreshment. The first method is by using the Extended RTP Profile for RTCP-based Feedback and sending RTCP generic control packets, as described in RFC 4585 [RFC4585]. The second method is by using application protocol-specific commands, such as H.245 [ITU.H245] FastUpdateRequest. 🌸

6. IANA Considerations 👑

This section updates the H.261 media type described in RFC 3555 [RFC3555].

This section specifies optional parameters that MAY be used to select optional features of the payload format. The parameters are specified here as part of the MIME subtype registration for the ITU-T H.261 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameters. 🎀

6.1. Media Type Registrations 🦋

This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555]. This registration uses the template defined in RFC 4288 [RFC4288]

6.1.1. Registration of MIME Media Type video/H261 ✨

okay so this is the official MIME registration form for H.261, and bestie, it's giving very official but also kind of iconic 💅

• MIME media type name: video
• MIME subtype name: H261
• Required parameters: None
• Optional parameters:
  • CIF: written as parameter=value. It tells you the maximum frame rate you can handle at CIF resolution. Valid values are integers from 1 to 4, and the max rate works out to 29.97/specified value 🎀
  • QCIF: also parameter=value, and it's the same deal for QCIF resolution. Valid values are integers from 1 to 4, and the max rate is 29.97/specified value 🌸
  • D: this one turns on still image graphics from H.261 annex D 🖼️ If you support it, the value SHALL be "1". If you don't, the parameter SHOULD NOT be used, or it SHALL have the value "0". no cap, very clear rules 🫶
• Encoding considerations: this media type is framed and binary. See Section 4.8 in [RFC4288].
• Security considerations: See Section 8 🔐
• Interoperability considerations: these are receiver options, and current implementations won't put any optional parameters in their SDP 🙈 They'll just ignore them and encode the H.261 stream without annex D. Most decoders handle at least QCIF, and they're expected to show up in almost every H.261-based video app. literally everywhere 🌈
• Published specification: RFC 4587
• Applications that use this media type: audio and video streaming and conferencing apps 📞
• Additional information: None
• Person and email address to contact for further information: Roni Even: roni.even@polycom.co.il 💌
• Intended usage: COMMON
• Restrictions on usage: this media type depends on RTP framing, so it's only defined for transfer via RTP [RFC3550]. Transport over other framing protocols isn't defined at this time 🚫
• Author: Roni Even 👑
• Change controller: IETF Audio/Video Transport working group, delegated from the IESG 🧚

6.2. SDP Parameters

okay, now the SDP mapping. This is how the video/H261 MIME type shows up in SDP fields, and it's lowkey so important 🦋

• The media name in the m= line of SDP MUST be video.
• The encoding name in the a=rtpmap line MUST be H261 (that's the MIME subtype).
• The clock rate in the a=rtpmap line MUST be 90000.
• The optional parameters CIF, QCIF, and D, if you use any, SHALL be included in the a=fmtp line of SDP. They're written as a MIME media type string, which is basically a semicolon-separated list of parameters 🍓

6.2.1. Usage with the SDP Offer Answer Model

when H.261 gets offered over RTP using SDP in an Offer/Answer model [RFC3264], there are a few things you need to keep in mind 💖

• Codec options (D): this option MUST NOT appear unless the sender of this SDP message can actually decode it. It SHALL be treated as a receiver's capability, even when it shows up in a "sendonly" offer 🙅‍♀️

Picture sizes and MPI: supported picture sizes and their matching minimum picture interval (MPI) info can be combined for H.261 ✨ You can advertise every picture size to the other party, or just a subset. Using the recvonly or sendrev direction attribute, a terminal SHOULD announce the picture sizes (with their MPIs) that it's willing to receive. For example, CIF=2 means the receiver can take a CIF picture, and the frame rate SHALL be less then 15 frames per second 🎞️

When the direction attribute is sendonly, the parameters describe what the stream's sender is able to produce 📤

Implementations that follow this spec SHALL specify at least one supported picture size 📏

If the receiver doesn't specify the picture size/MPI parameter, then it's safe to assume it's an implementation that follows RFC 2032. In that case, it is RECOMMENDED to assume that such a receiver can handle QCIF resolution with MPI=1 🌱

The parameters offered first are the most preferred picture mode to be received 🥇

Here's an example of media representation in SDP, CIF at 15 frames per second, QCIF at 30 frames per second, and annex D:

m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1

so this means the sender of this message can decode an H.261 bitstream with these options and parameters. The preferred resolution is CIF (its MPI is 2), but if that's not possible, QCIF is supported too. Still images using annex D MAY be used 🖼️

---

7. Backward Compatibility to RFC 2032 🔁

this section covers the big backward compatibility issues, because this doc replaces RFC 2032 🫶

7.1. Optional H.261-Specific Control Packets

RFC 2032 defined two H.261-specific RTCP control packets, "Full INTRA-frame Request" and "Negative Acknowledgement". Supporting them was optional 🤷‍♀️ These control packets are different from normal RTCP packets, because they don't go to the normal RTCP destination transport address for the RTP session (which is often a multicast address). Instead, they're sent straight over unicast from the decoder to the encoder. Their destination port is the same port the encoder uses as the source port for sending RTP (data) packets, so they can be called "reverse" control packets 🔄 This memo suggests generic methods for the same need. The document authors aren't aware of any products that support these control packets 👀 Since they're optional features, new implementations SHALL ignore them, and they SHALL NOT be used by new implementations 🚫

7.2. New SDP Optional Parameters

this doc adds new optional parameters to the H261 payload type 🎀 Since they're optional, we expect old implementations to ignore them. New implementations that get H.261 payload type capabilities with no parameters will assume they're dealing with an old implementation, and they'll send H.261 at QCIF resolution and 30 frames per second 🌷

---

8. Security Considerations 🔐

okay, this part is serious, so let's go 🚨

RTP packets using the payload format defined in this spec are subject to the security considerations in the RTP specification [RFC3550], and in any appropriate RTP profile (for example, [RFC3551]). This means confidentiality of the media streams is achieved by encryption. SRTP [RFC3711] may be used to provide both encryption and integrity protection of the RTP flow. Because the data compression used with this payload format is applied end to end, encryption happens after compression, so there's no conflict between the two operations ✨

there's a potential denial-of-service threat for data encoding that uses compression techniques with non-uniform receiver-end computational load 💀 An attacker can inject pathological datagrams into the stream that are complex to decode, and that can overload the receiver. Using authentication on at least the RTP packet is RECOMMENDED. H.261 is vulnerable to these attacks, because an attacker can generate RTP packets with frames that affect the decoding of future frames 😱 So using data origin authentication and data integrity protection on at least the RTP packet is RECOMMENDED; for example, with SRTP 🛡️

Note that the right mechanism for keeping RTP packets and their payloads confidential and intact really depends on the application and on the transport and signaling protocols in use. So even though SRTP is given as an example above, other choices exist 🌈

---

9. Acknowledgements 🙏

this is a shoutout to the authors of RFC 2032, Thierry Turletti and Christian Huitema 💜 Special thanks to Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped draft the text for the new MIME types 🫶

---

10. Changes from RFC 2032 📝

here's what changed from RFC 2032:

1. The H.261 MIME type is now in the payload specification.
2. Optional parameters were added to the H.261 MIME type.
3. The H.261-specific control packets were deprecated.
4. Editorial changes were made to line up with RFC editing procedures.

---

11. References 📚

11.1. Normative References

• [H261] International Telecommunications Union, "Video codec for audiovisual services at px 64 kbit/s", ITU Recommendation H.261, March 1993.
• [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.
• [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
• [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
• [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
• [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

11.2. Informative References

• [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
• [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.
• [ITU.H245] International Telecommunications Union, "CONTROL PROTOCOL FOR MULTIMEDIA COMMUNICATION", ITU Recommendation H.245, 2003.
• [INRIA] Turletti, T., "H.261 software codec for videoconferencing over the Internet", INRIA Research Report 1834, January 1993.
• [IVS] Turletti, T., "INRIA Videoconferencing tool (IVS)", available by anonymous ftp from zenon.inria.fr in the "rodeo/ivs/last_version" directory. See also URL <http://www.inria.fr/rodeo/ivs.html>.
• [BT601] International Telecommunications Union, "Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios", ITU-R Recommendation BT.601-5, October 1995.
• [MICE] Sasse, MA., Bilting, U., Schultz, CD., and T. Turletti, "Remote Seminars through MultiMedia Conferencing: Experiences from the MICE project", Proc. INET'94/JENC5, Prague pp. 251/1-251/8, June 1994.
• [VIC] MacCanne, S., "VIC Videoconferencing tool, available by anonymous ftp from ee.lbl.gov in the "conferencing/vic" directory".
• [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
• [H221] International Telecommunications Union, "Frame structure for a 64 to 1920 kbit/s channel in audiovisual teleservices", ITU Recommendation H.221, May 1999.

Author's Address 🎀

Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva  49130
Israel

EMail: roni.even@polycom.co.il

Full Copyright Statement ✨

okay so the legal bit first, bestie 📜 Copyright (C) The Internet Society (2006). this document is subject to the rights, licenses and restrictions in BCP 78, and except as stated there, the authors keep all their rights 🔒

the document and everything in it is provided "AS IS" 🫶 and THE CONTRIBUTOR, the organization they represent or sponsor (if any), THE INTERNET SOCIETY, and the INTERNET ENGINEERING TASK FORCE all disclaim every warranty, express or implied 🙅‍♀️ that includes no promise that using the info won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 💀

Intellectual Property 🎀

the IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) might cover the tech in here, or whether any license for them is available 🤷‍♀️ it also doesn't claim it has searched for those rights itself 🙈 if you want the rules on rights for RFC docs, check BCP 78 and BCP 79 💅

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the result of trying to get a general license or permission for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🌸

and the IETF is totally inviting anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🦋 send that info to the IETF at ietf-ipr@ietf.org 💜

Acknowledgement 🧚

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🍓✨