Network Working Group X. Marjou Internet-Draft J. Jestin Intended status: Standards Track France Telecom Expires: December 28, 2008 June 26, 2008 RTP Payload Format for Geographical Location. draft-marjou-geopriv-avt-geoloc-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 28, 2008. Abstract This memo presents some use-cases and requirements related to the real-time transport of geographical location information. It also defines a Real-time Transport Protocol (RTP) packet payload format to carry real-time geographical location information. Marjou & Jestin Expires December 28, 2008 [Page 1] Internet-Draft RTP Payload Format for Geoloc June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Media Format Background . . . . . . . . . . . . . . . . . . . 4 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 5 5.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5 5.2.1. Latitude Element . . . . . . . . . . . . . . . . . . . 6 5.2.2. Longitude Element . . . . . . . . . . . . . . . . . . 6 5.2.3. Altitude Element . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Payload Example . . . . . . . . . . . . . . . . . . . . . 7 6.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 7. Congestion Control Considerations . . . . . . . . . . . . . . 7 8. Payload Format Parameters . . . . . . . . . . . . . . . . . . 7 8.1. Media Type Definition . . . . . . . . . . . . . . . . . . 7 8.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative references . . . . . . . . . . . . . . . . . . . 8 12.2. Informative references . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Marjou & Jestin Expires December 28, 2008 [Page 2] Internet-Draft RTP Payload Format for Geoloc June 2008 1. Introduction Nowadays several applications share geographical location information. For example, in the context of VoIP, location information can already be exchanged between different users by the means of protocols such as SIP or HTTP. The location data is typically exchanged once, or a few times during a session. However some moving users may want to share their geographical location for a long duration so that remote users can instantaneously watch their current location. In the same vein, during a car race, a live show may want to permanently multicast the geographical location in addition to the video filmed from the inside of a vehicle. In this type of use-case the geographical location data needs to be transported many times per minute in order to reflect the correct location. Section 3 details the requirements needed by such use-cases Based on these requirements, the conclusion is that the Real-time Transport Protocol (RTP) [RFC3550] is a natural choice to transport geographical location data in case of real-time transmission scenarios and that a payload format needs to be specified, which is done in the following sections of this document. As this stage, it is still too early to dive into the details of a solution, which means that Section 5 to Section 9 are only a skeleton that gives a view of the topics that may be addressed in future versions of the draft Section 10 discusses the security issues. 2. Conventions, Definitions and Acronyms In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. Geographical location object: entity made of different elements like longitude, latitude, and altitude, all belonging to the same instance of a geographical location. 3. Requirements The solution for transporting real-time geographical location needs Marjou & Jestin Expires December 28, 2008 [Page 3] Internet-Draft RTP Payload Format for Geoloc June 2008 to fulfill the following requirements: REQ-1 The protocol MUST support real-time transport of geographical location (i.e. small delays, small overhead ...). REQ-2 The protocol MUST allow the synchronization of geographical location data with other types of media (e.g. video). REQ-3 The protocol MUST allow the streaming of geographical location data using multicasting. REQ-4 The protocol MUST be able to transport geographical latitude, longitude, and altitude. REQ-5 The protocol SHOULD be able to transport speed and compass direction. REQ-6 [[Additional geographical parameters? E.g. : would anyone need civic data?]] REQ-7 [[Do we want a mechanism that allows to set the precision of the transmitted data?]] Based on these requirements, we can say that REQ1, RE2, and REQ3 can be fulfilled thanks to the RTP protocol [RFC3550], while the other REQs can be achieved with a payload format dedicated to the transport of geographical location. 4. Media Format Background A first question about geographical localisation data is whether there is an already specified format that could be used in an RTP payload. Historically, NMEA 0183 [NMEA 0183] has been the most widely used standard in order to transport GPS data. One may think about reusing NMEA messages into RTP packets. However, this approach suffers a number of drawbacks: 1 - NMEA standard does not only describe the format of geographical data, but is also tied to serial link interfaces, which means that additional details would be needed to indicate what is kept from NMEA or not when using its messages in an RTP payload. 2 - There are many NMEA messages, which would require an out-of-band negotiation to select the wanted messages. Another widely used format for geographical location is the Keyhole Markup Language (KML) [KML] promoted by applications such as Google Marjou & Jestin Expires December 28, 2008 [Page 4] Internet-Draft RTP Payload Format for Geoloc June 2008 Maps or Google Earth. One may also think about using this file format into RTP packet payloads. However, this approach also suffers some drawbacks: 1 - KML format is targeted to annotation and visualization on geographical rendering applications. Though geographical data is definitely present, other types of data related to the GUI (e.g. orientation views, scales, ...) are far beyond the requirements of this document. PIDF-LO [RFC4119] is an IETF standard that describes an object format for carrying geographical information on the Internet. While this format transports GPS like information, it has 2 drawbacks: 1 - It can contain civic location, which is not needed according to the current requirements. 2 - The content is described in XML content, which may generate some few additional overhead. As there is no suited format for exchanging data, there is some sense to define a new format for RTP payload data. 5. Payload Format 5.1. RTP Header Usage The first part of an RTP packet is made of the fixed RTP header fields. The three fields set by the application in the fixed RTP header, timestamp, marker bit and payload type are explained here. For this payload format these fields should be interpreted and defined as following: Timestamp: The timestamp is used for identifying the time when the location object was acquired by the sender. One packet must carry a single location object. Marker bit (M bit): The marker bit is always set to zero. Payload Type (PT): The payload type is set dynamically and out of band in accordance with current practice. 5.2. Payload Data This section defines a number of general elements making part of the geographical location object. In this section, it is important to limit the total length taken by the different attributes in order to have an object of small length and avoid fragmentation. All elements start with an eight-bit identifier. These identifiers Marjou & Jestin Expires December 28, 2008 [Page 5] Internet-Draft RTP Payload Format for Geoloc June 2008 are taken from two different number spaces. The numbers 0-127 are used a common number space, identifying general elements and must be registered with IANA. Numbers 128-255 are left for future extensions, if any. An object SHALL only be present a single time in each packet. 5.2.1. Latitude Element The latitude element (LAT) is used by applications to send the latitude. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | El.type (1) | Len | Latitude : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len: Number of bytes that the element consists of. Latitude: Value of the element. [[TODO: discuss the exact data format in next version.]] 5.2.2. Longitude Element The longitude element (LON) is used by applications to send the longitude. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | El.type (2) | Len | Longitude : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len: Number of bytes that the element consists of. Valid lengths are 0-255, where 0 is allowed but lacks purpose. Longitude: Value of the element. Marjou & Jestin Expires December 28, 2008 [Page 6] Internet-Draft RTP Payload Format for Geoloc June 2008 5.2.3. Altitude Element The altitude element (ALT) is used by applications to send the altitude. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | El.type (2) | Len | Altitude : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Len: Number of bytes that the element consists of. Altitude: Value of the element. 6. Examples 6.1. Payload Example [[TODO: Add an example]] 6.2. SDP Example Below is an example of SDP describing RTP geographical location packets within the same RTP session from port 40000 and at a maximum rate of 1000 geographical location objects per second: m=application 40000 RTP/AVP 98 a=rtpmap:98 geoloc/1000 a=sendonly 7. Congestion Control Considerations 8. Payload Format Parameters 8.1. Media Type Definition Type name: application Subtype name: geoloc Marjou & Jestin Expires December 28, 2008 [Page 7] Internet-Draft RTP Payload Format for Geoloc June 2008 Required parameters: rate. The typical rate is 1000; other rates may be specified. [[TODO: Additional details will be added in a future version of the draft, when the overall framework is validated.]] 8.2. Mapping to SDP [[TODO: discuss if parameters can be negotiated.]] 9. IANA Considerations This document has no actions for IANA. 10. Security Considerations In the context of real-time geographical location information sent in RTP, geographical location can be considered as a regular media, as voice or video. Thus, when there are some privacy concerns about sharing the location, the traditional "phone" establishment session can apply: thanks to a session control protocol such as SIP, users can authenticate the remote peer and they are free to share or not their geographical location information within the multimedia session. Otherwise, as the geographical location is transported with RTP, all of the security considerations from Section 14 of RFC3550 [RFC3550] apply. 11. Acknowledgements Useful comments and feedback were provided by Aurelien Sollaud. 12. References 12.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Marjou & Jestin Expires December 28, 2008 [Page 8] Internet-Draft RTP Payload Format for Geoloc June 2008 12.2. Informative references [KML] "KML", . [NMEA 0183] "NMEA 0183", . [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Authors' Addresses Xavier Marjou France Telecom 2, avenue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Jean Francois Jestin France Telecom 2, avenue Pierre Marzin Lannion 22307 France Email: jeanfrancois.jestin@orange-ftgroup.nospam Marjou & Jestin Expires December 28, 2008 [Page 9] Internet-Draft RTP Payload Format for Geoloc June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Marjou & Jestin Expires December 28, 2008 [Page 10]