Internet Engineering Task Force           Civanlar & Cash - AT&T
  INTERNET DRAFT                            January 31, 2000
  File: draft-ietf-avt-pointer-01.txt       Expires: July 31, 2000

                RTP Payload Format for Real-Time Pointers

                           STATUS OF THIS MEMO

  This document is an Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet- Drafts as reference
  material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at

  The list of Internet-Draft Shadow Directories can be accessed at


  This document describes an RTP [1] payload format for transporting the
  coordinates of a dynamic pointer that may be used during a
  presentation. Although a mouse can be used as the pointer, this
  payload format is not intended and may not have all functionalities
  needed to implement a general mouse event transmission mechanism.

  This version of the draft includes MIME type registration information
  and a wording change in Section 2.2 for clarification.

  1. Introduction

  In most presentations, significant information is conveyed through the
  use of viewgraphs and a pointer. This makes accurate transmission of
  them vital in remote conferencing applications. Using regular video of
  a presenter's display for this purpose is problematic because, while
  the viewgraphs require a high spatial resolution, the pointer
  movements need to be sampled and transmitted at a high temporal

Civanlar & Cash                                                 [Page 1]

INTERNET-DRAFT     RTP Payload Format for Real-Time PointersJanuary 2000

  resolution so that the presenter's pointing actions can be displayed
  synchronously with the corresponding audio and video signals. In many
  instances, this synchronization carries vital information.  As an
  example, consider a speaker pointing at two alternatives on a
  viewgraph in sequence and saying "this one is better than this." To
  satisfy both high spatial and high temporal resolution requirements,
  at least S-VHS quality video may need to be used. Codecs that can
  compress S-VHS video effectively in real-time are expensive for this
  purpose, and transmitting such video uncompressed requires very high

  A much simpler and economical system can be designed by capturing and
  transmitting the pointer coordinates separately [2]. The pointer
  coordinates with respect to a displayed viewgraph can easily be
  obtained in electronic presentation systems. For presentations
  prepared for optical systems, such as transparencies for overhead
  projectors, an arrangement where the viewgraph is captured in a frame
  buffer on a computer can be used to associate the pointer coordinates
  with the displayed viewgraph. For capturing transparencies, printed
  material, or even three dimensional objects, a document camera and a
  personal computer or workstation based video capture card can be used.
  This arrangement can handle electronic viewgraphs by feeding the video
  output of the computer that displays them to the video capture card
  through an appropriate converter also. A side benefit of this is that
  it allows using a presenter's own computer to transmit electronic
  viewgraphs without connecting it to, for example, an intranet. The
  captured image is then displayed along with the capturing computer's
  mouse pointer on the presenter's display using a projector. The
  presenter moves the pointer on the display using a regular or maybe a
  wireless mouse whose location can easily be captured by appropriate
  software running on the capturing computer.

  This document describes an RTP payload format to transmit the pointer
  coordinates captured in one of the ways described above using RTP.
  Although, a mouse can be used as the pointer, this payload format is
  not intended and may not have all functionalities needed to implement
  a  general mouse event transmission mechanism.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  document are to be interpreted as described in RFC 2119 [3].

Civanlar & Cash                                                 [Page 2]

INTERNET-DRAFT     RTP Payload Format for Real-Time PointersJanuary 2000

  2. Payload 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=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 does not have a payload specific header.

  2.1. RTP Header Usage:

  Payload Type (PT): The assignment of an RTP payload type for this new
  packet format is outside the scope of this document, and will not be
  specified here. It is expected that the RTP profile for a particular
  class of applications will assign a payload type for this encoding, or
  if that is not done then a payload type in the dynamic range shall be

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

  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 are used as described in RFC 1889 [1].

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

Civanlar & Cash                                                 [Page 3]

INTERNET-DRAFT     RTP Payload Format for Real-Time PointersJanuary 2000

  2.2. Payload:

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

  L (left), R (right) and/or M (middle) bits are set to one if their
  respective "mouse" buttons are down at the sampling time.

  PIN: Pointer Icon Number (3 bits) selects a pointer icon.  The
  association between the PIN numbers and the icon pictures MUST be
  established out-of-band. PIN = 0 represents a default pointer icon.

  3. MIME Media Type Registrations

  This document defines a new RTP payload name, "pointer," and
  associated MIME subtype, "video/pointer." The registration form for
  this MIME subtype has been submitted to IANA.

  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 "draft-ietf-avt-pointer-01".

       Security considerations: As described in "draft-ietf-avt-pointer-01"

       Interoperability considerations: None

       Published specification: draft-ietf-avt-pointer-01

       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

Civanlar & Cash                                                 [Page 4]

INTERNET-DRAFT     RTP Payload Format for Real-Time PointersJanuary 2000

       Person & email address to contact for further information:
         M. Reha Civanlar

       Intended usage: COMMON
       Author/Change controller:
         M. Reha Civanlar

  4. Security Considerations

  RTP packets using the payload format defined in this specification are
  subject to the security considerations discussed in the RTP
  specification [1].

  This payload type does not exhibit any significant non-uniformity in
  the receiver side computational complexity for packet processing  to
  cause a potential denial-of-service threat.

  4. References

    [1] Schulzrinne, Casner, Frederick, Jacobson RTP: A
    Transport Protocol for Real Time Applications  RFC 1889,
    Internet Engineering Task Force, January 1996.

    [2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG" Proceedings
    of The 9th Int. Workshop on Packet Video,

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

 7. Authors' Addresses

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

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

Civanlar & Cash                                                 [Page 5]