One document matched: draft-marjou-geopriv-avt-geoloc-00.txt
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", <http://code.google.com/apis/kml/documentation/
kmlreference.html>.
[NMEA 0183]
"NMEA 0183", <http://www.nmea.org/pub/0183/index.html>.
[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]
| PAFTECH AB 2003-2026 | 2026-04-23 21:35:27 |