Internet DRAFT - draft-crowcroft-rtcp-latlong
draft-crowcroft-rtcp-latlong
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:26:03 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 26 Feb 1999 19:06:00 GMT
ETag: "2e7fe5-1317-36d6f098"
Accept-Ranges: bytes
Content-Length: 4887
Connection: close
Content-Type: text/plain
Internet Engineering Task Force J Crowcroft
INTERNET DRAFT UCL
February 1999
RTCP location reports
<draft-crowcroft-rtcp-latlong-00.txt>
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This note is a proposal to add lat/long data to RTCP reports to
enable transport protocols, and applications to carry out a number of
useful tasks.
1.0 Introduction
This is a proposal to add geographical location reporting data into
RTCP reports in the AVT work, as an "APP: Application specific
function", but with an agreed format (T,L,V) so that they can be
shared across multiple uses.
1.0 Rationale
Expires August 1999 ^L[Page 1]
Internet Draft Simple Multicast February 1999
It would be useful to know where participants are geographically
located in an RTP session.
Reasons for this information are legion: Many systems can now render
audio (and even video) data in 3D - actual location could be mapped
into the receviers rendering space
Change in position over time maps to velocity - this information can
be used by mobile IP to provide similar functions to power metering
in the physical layer for wireless networking.
Positional information can help with routing, particularly to media
(or H.323/SIP) gateway selection (load balancing).
As the network gets faster and faster, the geographical distance
between two sites domiantes the end2end delay. It is hard to do RTT
estimation in a multicast session without clock synchronisation, but
to at least a first approximation, distance/c = delay.
Some applications utilise retransmissions to gain reliability (many
use FEC, but in short haul interactive sessions, and in streaming
apps, retransmits are reasonable). Many retransmit schems build a
self organising system (tree, ring etc) to help decide where to
source retransmits from (SRM, RMTP etc etc). Geogrqaphical location
would be another hint for these algorithms.
Geographical information might allow better synchronisation.
Geographic (distance) based billing may be needed by some providers
(e.g. of internet telephony).
Some folks have proposed geogrpahic based addresses. Howeever,
without these, there may also be some room for geographic based
scoping (and correlation with multicast zone checking schemes).
I am sure there are other uses.
1.0 Formats
The RTP RFC defines the format within which we add such application
specific data. WIthin this, we have to choose a format for the data
itself.
There are a number of different formats that already exist for
carrying geographic location information. In keeping with the
internet multimedia design principles, we want an extensible
protocol, this we code the position field as a {Type, Length, Value}
triple. Because it needs to be decoded fast (may be handed to an
Expires August 1999 ^L[Page 2]
Internet Draft Simple Multicast February 1999
active filter in an audio renderer), some formats may be binary and
hardwired into applications - so be it...
The code points for type will be assigned by the IANA.
It would be interesting to add the same data in session announcements
as per SAP - A congruent SDP defined field would suffice.
4 Acknowledgments
Thanks to Colin Perkins for some suggestions.
References
RFC 1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video
Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick & V.
Jacobson. January 1996.
RFC 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998.
Authors' Addresses
Jon Crowcroft
Department of Computer Science
University College London
Gower Street
London, WC1E 6BT, UK
J.Crowcroft@cs.ucl.ac.uk
Expires August 1999 ^L[Page 3]
