From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2862.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2862.txt (limited to 'doc/rfc/rfc2862.txt') 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] + -- cgit v1.2.3