idnits 2.17.1 draft-schulzrinne-sipping-sos-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: ---------------------------------------------------------------------------- ** 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 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 54: '... It is RECOMMENDED that SIP-based [2] end systems and proxy servers...' RFC 2119 keyword, line 64: '...ents and proxies SHOULD also recognize...' RFC 2119 keyword, line 66: '... agents SHOULD recognize local emerg...' RFC 2119 keyword, line 67: '... servers MUST be configurable to rec...' RFC 2119 keyword, line 77: '... A user agent SHOULD direct such a r...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 13, 2001) is 8322 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) -- Missing reference section? '1' on line 132 looks like a reference -- Missing reference section? '2' on line 136 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Schulzrinne 4 draft-schulzrinne-sipping-sos-00.txt Columbia U. 5 July 13, 2001 6 Expires: December 2001 8 Universal Emergency Address for SIP-based Internet Telephony 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a universal emergency SIP URL, sip:sos@domain, 34 that allows SIP user agents to contact the local emergency number. 36 1 Introduction 38 Using the PSTN, emergency help can often be summoned at a designated, 39 widely known number, regardless of where the telephone was purchased. 40 However, this number differs between localities. For SIP-based end 41 systems, it is desirable to have a universal identifier, independent 42 of location, to simplify the user experience and to allow the device 43 to perform appropriate processing. Here, we define a common user 44 identifier, "sos", as the contact mechanism for emergency assistance. 46 1.1 Terminology 47 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 48 "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 49 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 50 indicate requirement levels for compliant SIP implementations. 52 2 Emergency URL 54 It is RECOMMENDED that SIP-based [2] end systems and proxy servers 55 support a uniform emergency call identifier, namely the user name 56 "sos" at any domain, e.g., 58 sip:sos@local-domain 60 Here, "local-domain" is replaced the local domain of the network to 61 which the user agent is connected. For examle, if a UA is currently 62 in the "example.com" domain, it would use sip:sos@example.com. 64 In addition, user agents and proxies SHOULD also recognize the 65 telephone number 911 and 112 for this purpose. Where feasible, user 66 agents SHOULD recognize local emergency numbers. Outbound proxy 67 servers MUST be configurable to recognize additional local emergency 68 numbers. [? TBD] 70 There are about 60 short numbers for emergency services in 71 the world; including them all is not practical, as that 72 would interfere with existing local two, three and four- 73 digit dialing plans. 75 3 Request Handling 77 A user agent SHOULD direct such a request to a local proxy server, if 78 configured, or send the request to the SIP multicast address. 80 It is possible that there are several SIP proxies listening to the 81 same multicast address, each routing the request independently to 82 different emergency call centers. Proxies in such configurations MUST 83 take steps to prevent this from occuring, for example to route the 84 call based on the caller's identity or location. Determining and 85 conveying the location of the caller is beyond the scope of this 86 document. 88 The multicast mechanism differs slightly from standard SIP 89 processing; the use of an outbound proxy conforms to 90 standard procedures. Multicast allows systems to make 91 emergency calls with minimal configuration. 93 Using a server that is local to the user agent is more likely to 94 reach a geographically local server, although that is not guaranteed 95 if virtual private networks are being used. 97 The "sos" user name MUST NOT be assigned to any regular user. It is 98 RECOMMENDED that SIP MESSAGE requests are directed to a TTY-for-the- 99 deaf translator. 101 User agent servers and proxy servers MUST NOT require that the user 102 agent client be registered or authenticated in order to place an 103 emergency call. 105 For testing purposes, OPTIONS messages to the user "sos" SHOULD 106 return an indication whether the address is defined, but cause no 107 further action. It is RECOMMENDED that user agents periodically 108 automatically check for the availability of the "sos"identifier and 109 alert the user if the check fails. The period of such automated 110 checks SHOULD NOT be less than once per day and MUST be randomly 111 placed over the testing interval. 113 Any proxy, outbound or otherwise, that receives such a request MUST 114 forward (proxy) or redirect the request to the appropriate local 115 emergency number (e.g., 911 in the United States or 112 in Europe). 116 Typically, the proxy server routes the call to an appropriate PSTN 117 gateway, translating the request URI to the local emergency number. 118 Any SIP PSTN gateway shall translate this emergency identifier to the 119 locally supported emergency number. 121 It is beyond the scope of this document how the proxy determines the 122 appropriate public safety answering point or how it determines the 123 physical location of the SIP UA making the request. 125 TBD: Should something like sip:sos@localhost be supported, for SIP 126 phones that do not know which is the local domain? (Generally, SIP 127 UAs would determine this information via DHCP or inverse DNS lookup 128 of their IP address.) 130 4 Bibliography 132 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 133 levels," Request for Comments 2119, Internet Engineering Task Force, 134 Mar. 1997. 136 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 137 session initiation protocol," Request for Comments 2543, Internet 138 Engineering Task Force, Mar. 1999. 140 5 Acknowledgements 142 James Polk and Brian Rosen contributed helpful comments. 144 6 Authors' Addresses 146 Henning Schulzrinne 147 Dept. of Computer Science 148 Columbia University 149 1214 Amsterdam Avenue 150 New York, NY 10027 151 USA 152 electronic mail: schulzrinne@cs.columbia.edu