summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2862.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2862.txt')
-rw-r--r--doc/rfc/rfc2862.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2862.txt b/doc/rfc/rfc2862.txt
new file mode 100644
index 0000000..22d4092
--- /dev/null
+++ b/doc/rfc/rfc2862.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group M. Civanlar
+Request for Comments: 2862 G. Cash
+Category: Standards Track AT&T
+ June 2000
+
+
+ RTP Payload Format for Real-Time Pointers
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+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 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.
+
+
+
+
+
+Civanlar & Cash Standards Track [Page 1]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 2000
+
+
+ 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 Standards Track [Page 2]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 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 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 Standards Track [Page 3]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 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 pointer special
+ effects flags. Their use is application dependent and MUST be
+ established out-of-band. Applications MAY ignore these bits.
+
+ 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.
+ Applications which 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.
+
+3. MIME Media Type Registrations
+
+ This document defines a new RTP payload name, "pointer," and
+ 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
+
+
+
+Civanlar & Cash Standards Track [Page 4]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 2000
+
+
+ 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
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash Standards Track [Page 5]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 2000
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash Standards Track [Page 6]
+
+RFC 2862 RTP Payload Format for Real-Time Pointers June 2000
+
+
+7. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash Standards Track [Page 7]
+