Internet Engineering Task Force Civanlar & Cash - AT&T INTERNET DRAFT October 4, 1999 File: draft-ietf-avt-pointer-00.txt Expires: April, 4 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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. 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 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 Civanlar & Cash [Page 1] INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999 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 bandwidths. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Civanlar & Cash [Page 2] INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999 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 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 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 Pointers June 1999 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 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. 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, http://www.reseach.att.com/~mrc/PacketVideo99.html. [3] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. Civanlar & Cash [Page 4] INTERNET-DRAFT RTP Payload Format for Real-Time Pointers June 1999 7. Authors' Addresses M. Reha Civanlar AT&T Labs - Research 100 Schultz Drive Room 3-205 Red Bank, NJ 07701 USA e-mail: civanlar@research.att.com Glenn L. Cash AT&T Labs - Research 100 Schultz Drive Room 3-213 Red Bank, NJ 07701 USA e-mail: glenn@research.att.com Civanlar & Cash [Page 5]