RFC 2862

RTP Payload Format for Real-Time Pointers

📅 published June 2000, from ietf

RFC 2862: RTP Payload Format for Real-Time Pointers 🎀

Okay bestie, here's the title block 💖 This one is by M. Civanlar and G. Cash from AT&T 🦋. It's a Standards Track doc, dated June 2000, and it doesn't obsolete or update anything (no Obsoletes or Updates lines in the header) ✨.

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 💅. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2000). All Rights Reserved. 🫶

Abstract ✨

This doc describes an RTP [1] payload format for sending the coordinates of a dynamic pointer that might get used during a presentation 🦋. A mouse can be the pointer, but this payload format isn't meant for that and may not have everything you'd need for a general mouse event transmission mechanism 🙈.

1. Introduction 💖

In most presentations, the important stuff gets shared through viewgraphs and a pointer 📊. So getting them across accurately is super vital in remote conferencing apps 🔥. Sending regular video of the presenter's display is kind of a mess for this, because viewgraphs need really high spatial resolution, but the pointer movements need to be sampled and sent at a really high temporal resolution so the pointing lines up with the audio and video 😭. Honestly the sync is often the vital info!! Picture a speaker pointing at two options on a viewgraph, one then the other, saying "this one is better than this" 👀. To nail both the high spatial and high temporal needs, you'd probably need at least S-VHS quality video. Compressing S-VHS in real time is pricey for this, and sending it uncompressed takes insane bandwidth 💀.

A much simpler and cheaper setup is to capture and send the pointer coordinates separately [2] 💅. Electronic presentation systems can easily get the pointer coordinates relative to a displayed viewgraph ✨. For stuff made for optical systems, like overhead projector transparencies, you can capture the viewgraph into a frame buffer on a computer and link the pointer coordinates to it 🌸. For transparencies, printed material, or even 3D objects, you can use a document camera plus a PC or workstation video capture card 📸. This setup can also handle electronic viewgraphs, by feeding the video output of the computer displaying them into the capture card through a suitable converter 🔌. A bonus is that the presenter can use their own computer to send electronic viewgraphs without hooking it up to something like an intranet 🧚. The captured image then gets shown with the capturing computer's mouse pointer on the presenter's display through a projector 🎀. The presenter moves the pointer with a regular mouse (or maybe a wireless one), and software on the capturing computer can easily track where it is 🦋.

This doc describes an RTP payload format for sending pointer coordinates captured in any of those ways using RTP 💜. Again, a mouse can be the pointer, but this payload format isn't meant for that and may not have all the functionality needed for a general mouse event transmission mechanism 🙈.

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 RFC 2119 [3] 👑.

2. Payload Format 🌈

Here's the packet layout, bestie, check it out 👇

    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=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            contributing source (CSRC) identifiers             :
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |L|M|R| |     x-coordinate      | | PIN |     y-coordinate      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         MBZ                       MBZ

               Figure 1 - An RTP packet for Real-Time Pointer

Fig. 1 shows an RTP packet carrying real-time pointer coordinates 🍓. This payload format has no payload-specific header, so that's a nice little freebie ✨.

2.1. RTP Header Usage: 🎀

Payload Type (PT): Assigning an RTP payload type for this new packet format is outside this doc's scope, 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 🧚.

Marker (M) bit: Set to one if the pointer icon is changed in this packet 🦋.

Extension (X) bit: Defined by the RTP profile used 💅.

Sequence Number: Set as described in RFC1889 [1] 🔢.

Timestamp: The sampling time for the pointer location, measured by a 90kHz clock ⏰.

SSRC: Set as described in RFC1889 [1] 🫶.

CC and CSRC fields: These are used as described in RFC 1889 [1] 💜.

RTCP SHOULD be used as defined in RFC 1889 [1] 🌸.

2.2. Payload: 🌟

The pointer's x and y coordinates are measured from the upper left corner of the associated display window ✨. They're represented as a fraction of the corresponding edge length of the display window, using 12 bits. These are positive, fixed point numbers between 0 and (1 - 2^-12) 🔥.

The L (left), R (right), and/or M (middle) bits are pointer special effects flags 🦋. What they do is application dependent, and they MUST be established out-of-band 🙈. Applications MAY ignore these bits 💅.

PIN: The Pointer Icon Number (3 bits) selects a pointer icon 🎀. The association between PIN numbers and icon pictures MUST be established out-of-band 🧚. PIN = 0 represents a default pointer icon 🌈. Applications that only support a single pointer icon SHOULD set the PIN field to zero 👑. Applications MAY ignore non-zero PIN values on reception and display a default icon instead 💖.

3. MIME Media Type Registrations 🦋

This doc defines a new RTP payload name, "pointer," and its associated MIME subtype, "video/pointer" 💜.

3.1. Registration of MIME media type video/pointer 🌸

      MIME media type name: video

      MIME subtype name: pointer

      Required parameters: None

      Optional parameters: None

      Encoding considerations: Pointer video can be transmitted with RTP
      as specified in this document.

      Security considerations: As described in this document.

      Interoperability considerations: None

      Published specification: this document.

      Applications which use this media type: Videoconferencing systems
      that transmit VUgraphs with a real-time pointer.

      Additional information: None

        Magic number(s): None
        File extension(s): None
        Macintosh File Type Code(s): None

      Person & email address to contact for further information:
        M. Reha Civanlar
        e-mail: civanlar@research.att.com

      Intended usage: COMMON Author/Change controller:
        M. Reha Civanlar
        e-mail: civanlar@research.att.com

4. Security Considerations 🔥

Packets using the payload format defined in this spec are subject to the security considerations discussed in the RTP specification [1] 🛡️.

This payload type doesn't show any significant non-uniformity in receiver-side computational complexity for packet processing, so there's no potential denial-of-service threat from it 💅. No DoS drama here, periodt ✨.

5. References 📚

[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996. 🎀

[2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG", Proceedings of The 9th Int. Workshop on Packet Video, http://www.research.att.com/~mrc/PacketVideo99.html. 🦋

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

6. Authors' Addresses 🫶

   M. Reha Civanlar
   AT&T Labs - Research
   100 Schultz Drive, Room 3-205
   Red Bank, NJ 07701, USA

   EMail: civanlar@research.att.com


   Glenn L. Cash
   AT&T Labs - Research
   100 Schultz Drive, Room 3-213
   Red Bank, NJ 07701, USA

   EMail: glenn@research.att.com

Copyright (C) The Internet Society (2000). All Rights Reserved. ✨

You can copy and share this doc and translations of it, and you can make derivative works that comment on or explain it or help implement it. You can prepare, copy, publish, and distribute those, in whole or in part, with no restriction of any kind, as long as the copyright notice and this paragraph are on all copies and derivative works 🌈. But this document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards (then the Internet Standards process copyright procedures have to be followed) or to translate it into languages other than English 🌸.

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 🦋.

The doc and the info in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💖.

📦 where this page comes from