RFC 4573

RFC 4573: MIME Type Registration for RTP Payload Format for H.224 🎀

Okay bestie, RFC 4573 is a Standard Track doc from the Network Working Group 🌸 It was written by Roni Even and Andrew Lochbaum, both at Polycom, and it's dated July 2006. The header doesn't list anything it obsoletes or updates, so it's a fresh one. ✨

---

Status of This Memo 📜

This is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). The distribution of this memo is unlimited. 🦋

Copyright Notice ©️

Copyright (C) The Internet Society (2006). 💜

Abstract 🎬

In conversational video apps, participants use a far-end camera control protocol to move the remote camera around 📹 The protocol that's commonly used for this is ITU H.281 over H.224. This document registers the H224 media type 🎀 It also defines the syntax and semantics of the Session Description Protocol (SDP) parameters you need to run far-end camera control using H.224. It's giving "everything you need in one place" 😭

Table of Contents 🗂️

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Far-End Camera Control Protocol .................................2
4. IANA Considerations .............................................2
   4.1. Media Type Registration ....................................2
5. SDP Parameters ..................................................4
   5.1. Usage with the SDP Offer Answer Model ......................4
6. Security Considerations .........................................5
7. References ......................................................5
   7.1. Normative References .......................................5
   7.2. Informative References .....................................6

---

1. Introduction ✨

Okay so this doc registers the H224 media type 🦋 It's meant for systems that use SDP [RFC4566].

This media type supports the simple far-end camera control protocol on SDP-based systems. 🎥 It's lowkey the glue that helps signaling gateways between H.323 [ITU.H323] and SDP-based systems use far-end camera control end to end, with no protocol translation in the middle. Iconic, right? 👑

The reason this doc defines the H224 media type is that the RTP packets in H.323 annex Q [ITU.H323] carry H.224 frames [ITU.H224]. The far-end camera control protocol (FECC) lives inside the H.224 frame, and you can spot it by the client ID field of the H.224 packet. 🧚

The doc is also going to define the SDP [RFC4566] parameters needed to support that far-end camera control protocol in systems that use SDP. It's the whole plan, bestie 💖

2. Terminology 📚

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 [RFC2119]. They indicate requirement levels for compliant RTP implementations. These are the big capital words, and they're the ones that matter for the rules. 🫶

3. Far-End Camera Control Protocol 🎀

This simple protocol is based on ITU-T H.281[ITU.281] frames carried in ITU-T H.224 packets in an RTP/UDP channel. 🌈 H.323 annex Q explains how to build the RTP packets from the H.224 packets.

Using far end camera control protocol in point-to-point calls and multipoint calls for packet-switch networks is described in H.323, annex Q. So if you want the full picture, that's where to look 🔥

4. IANA Considerations 📋

4.1. Media Type Registration 🦋

This section describes the media types and names associated with this payload format. The registration uses the templates defined in RFC 4288 [RFC4288], and it follows RFC 3555 [RFC3555]. Very organized, very slay 💅

4.1.1. Registration of MIME Media Type application/h224 💖

Here's the registration, copied exactly as it's written so nothing gets lost in translation 🧾

MIME media type name: application

MIME subtype name: H224

Required parameters: None

Optional parameters: None

Encoding considerations:

   This media type is framed (see H.323, Annex Q [ITU.H323]) and
   contains binary data; see Section 4.8 of [RFC4288]

Security considerations: See Section 6 of RFC 4573.

Interoperability considerations:

   Terminals sending simple far-end camera control commands should
   use this MIME type.  Receivers who cannot support the protocol
   will reject the channel.

Published specification: RFC 4573

Applications that use this media type:

   Video conferencing applications.

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 and thus is only defined
   for transfer via RTP [RFC3550].  Transport within other framing
   protocols is not defined at this time.

Author: Roni Even

Change controller:

   IETF Audio/Video Transport working group, delegated from the IESG.

Heads up: the registration says the receivers who can't support the protocol will reject the channel. That's the interop vibe you need to know before you ship anything 💀

---

to be continued... 🌸 part 2 is coming up next with SDP Parameters, the Offer/Answer stuff, Security Considerations, and all the References 🦋

Intellectual Property ✨

okay so the IETF is basically saying "we are not picking a side" 💅 They take no position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this doc are valid, or how far they reach. They also might not be able to get you a license for them. And they did not go hunting for those rights themselves, so don't assume they checked 🙈 If you want the rules on rights for RFC documents, go read BCP 78 and BCP 79 📚

Any IPR disclosures sent to the IETF Secretariat live in the IETF's online IPR repository, along with any promises of licenses. The same goes for what happens when someone tries to get a general license or permission for implementers or users to use those proprietary rights. The repo is at http://www.ietf.org/ipr 🔗

The IETF also really wants to hear about it if you know of copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 💌 Literally the whole point is that nobody gets blindsided later 🫶

Acknowledgement

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🌸 So the people keeping these documents tidy are getting paid, and that's iconic 👑