Internet Engineering Task Force J Crowcroft INTERNET DRAFT UCL February 1999 RTCP location reports 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]