idnits 2.17.1 draft-crowcroft-rtcp-latlong-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 32 has weird spacing: '... useful tasks...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J Crowcroft 3 INTERNET DRAFT UCL 4 February 1999 6 RTCP location reports 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This note is a proposal to add lat/long data to RTCP reports to 31 enable transport protocols, and applications to carry out a number of 32 useful tasks. 34 1.0 Introduction 36 This is a proposal to add geographical location reporting data into 37 RTCP reports in the AVT work, as an "APP: Application specific 38 function", but with an agreed format (T,L,V) so that they can be 39 shared across multiple uses. 41 1.0 Rationale 42 It would be useful to know where participants are geographically 43 located in an RTP session. 45 Reasons for this information are legion: Many systems can now render 46 audio (and even video) data in 3D - actual location could be mapped 47 into the receviers rendering space 49 Change in position over time maps to velocity - this information can 50 be used by mobile IP to provide similar functions to power metering 51 in the physical layer for wireless networking. 53 Positional information can help with routing, particularly to media 54 (or H.323/SIP) gateway selection (load balancing). 56 As the network gets faster and faster, the geographical distance 57 between two sites domiantes the end2end delay. It is hard to do RTT 58 estimation in a multicast session without clock synchronisation, but 59 to at least a first approximation, distance/c = delay. 61 Some applications utilise retransmissions to gain reliability (many 62 use FEC, but in short haul interactive sessions, and in streaming 63 apps, retransmits are reasonable). Many retransmit schems build a 64 self organising system (tree, ring etc) to help decide where to 65 source retransmits from (SRM, RMTP etc etc). Geogrqaphical location 66 would be another hint for these algorithms. 68 Geographical information might allow better synchronisation. 70 Geographic (distance) based billing may be needed by some providers 71 (e.g. of internet telephony). 73 Some folks have proposed geogrpahic based addresses. Howeever, 74 without these, there may also be some room for geographic based 75 scoping (and correlation with multicast zone checking schemes). 77 I am sure there are other uses. 79 1.0 Formats 81 The RTP RFC defines the format within which we add such application 82 specific data. WIthin this, we have to choose a format for the data 83 itself. 85 There are a number of different formats that already exist for 86 carrying geographic location information. In keeping with the 87 internet multimedia design principles, we want an extensible 88 protocol, this we code the position field as a {Type, Length, Value} 89 triple. Because it needs to be decoded fast (may be handed to an 90 active filter in an audio renderer), some formats may be binary and 91 hardwired into applications - so be it... 93 The code points for type will be assigned by the IANA. 95 It would be interesting to add the same data in session announcements 96 as per SAP - A congruent SDP defined field would suffice. 98 4 Acknowledgments 100 Thanks to Colin Perkins for some suggestions. 102 References 104 RFC 1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video 105 Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick & V. 106 Jacobson. January 1996. 108 RFC 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998. 110 Authors' Addresses 112 Jon Crowcroft 113 Department of Computer Science 114 University College London 115 Gower Street 116 London, WC1E 6BT, UK 117 J.Crowcroft@cs.ucl.ac.uk