idnits 2.17.1 draft-schulzrinne-sipping-sos-01.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 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 55: '... It is RECOMMENDED that SIP-based [2] end systems and proxy servers...' RFC 2119 keyword, line 64: '...local domain, it MAY use the domain fr...' RFC 2119 keyword, line 67: '...ents and proxies SHOULD also recognize...' RFC 2119 keyword, line 70: '... SHOULD recognize additional, local ...' RFC 2119 keyword, line 71: '... servers MUST be configurable to rec...' (11 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 (February 19, 2002) is 8102 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 162 looks like a reference -- Missing reference section? '2' on line 166 looks like a reference Summary: 4 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 Columbia U. 5 draft-schulzrinne-sipping-sos-01.txt 6 February 19, 2002 7 Expires: July 2002 9 Universal Emergency Address for SIP-based Internet Telephony 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines a universal emergency SIP URL, sip:sos@domain, 35 that allows SIP user agents to contact the local emergency number. 37 1 Introduction 39 Using the PSTN, emergency help can often be summoned at a designated, 40 widely known number, regardless of where the telephone was purchased. 41 However, this number differs between localities. For SIP-based end 42 systems, it is desirable to have a universal identifier, independent 43 of location, to simplify the user experience and to allow the device 44 to perform appropriate processing. Here, we define a common user 45 identifier, "sos", as the contact mechanism for emergency assistance. 47 1.1 Terminology 48 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 49 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 50 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 51 indicate requirement levels for compliant SIP implementations. 53 2 Emergency URL 55 It is RECOMMENDED that SIP-based [2] end systems and proxy servers 56 support a uniform emergency call identifier, namely the user name 57 "sos" at any domain, e.g., 59 sip:sos@local-domain 61 Here, "local-domain" is replaced the local domain of the network to 62 which the user agent is connected. For example, if a UA is currently 63 in the "example.com" domain, it would use sip:sos@example.com. If 64 the system does not know the local domain, it MAY use the domain from 65 its address-of-record. 67 In addition, user agents and proxies SHOULD also recognize the 68 telephone numbers 911 and 112, expressed as a tel URL such as 69 tel:911 and tel:112, for this purpose. Where feasible, user agents 70 SHOULD recognize additional, local emergency numbers. Outbound proxy 71 servers MUST be configurable to recognize additional local emergency 72 numbers. [? TBD] 74 There are about 60 short numbers for emergency services in 75 the world; including them all is not practical, as that 76 would interfere with existing local two, three and four- 77 digit dialing plans. 79 In addition, we define subaddresses of sos, sos.fire, sos.rescue, 80 sos.police, to represent the local fire, rescue (ambulance) and 81 police emergency contacts, respectively. 83 In some areas, these emergency services use different 84 numbers. 86 3 Request Handling 88 A user agent SHOULD direct such a request to a outbound proxy server, 89 if configured, or send the request to the SIP multicast address. 91 It is possible that there are several SIP proxies listening to the 92 same multicast address, each routing the request independently to 93 different emergency call centers. Proxies in such configurations MUST 94 take steps to prevent this from occuring, for example to route the 95 call based on the caller's identity or location. Determining and 96 conveying the location of the caller is beyond the scope of this 97 document. 99 The multicast mechanism differs slightly from standard SIP 100 processing; the use of an outbound proxy conforms to 101 standard procedures. Multicast allows systems to make 102 emergency calls with minimal configuration. 104 Using a proxy server that is local to the user agent is more likely 105 to reach a geographically local server, although that is not 106 guaranteed if virtual private networks are being used. 108 The "sos" user name and user names starting with "sos." MUST NOT be 109 assigned to any regular user. It is RECOMMENDED that SIP MESSAGE 110 requests are directed to a TTY-for-the-deaf translator. 112 User agent servers and proxy servers MUST NOT require that the user 113 agent client be registered or authenticated in order to place an 114 emergency call. 116 For testing purposes, OPTIONS messages to the user "sos" and the 117 "sos.*" addresses (sos.fire, etc.) SHOULD return an indication 118 whether the address is defined, but cause no further action. It is 119 RECOMMENDED that user agents periodically automatically check for the 120 availability of the "sos"identifier and alert the user if the check 121 fails. The period of such automated checks SHOULD NOT be less than 122 once per day and MUST be randomly placed over the testing interval. 124 Any proxy, outbound or otherwise, that receives such a request MUST 125 forward (proxy) or redirect the request to the appropriate local 126 emergency number (e.g., 911 in the United States or 112 in Europe). 127 Typically, the proxy server routes the call to an appropriate PSTN 128 gateway, translating the request URI to the local emergency number. 129 Any SIP PSTN gateway shall translate this emergency identifier to the 130 locally supported emergency number. 132 If a proxy receives a "sos.*" request (such as sos.fire), the proxy 133 forwards it to the appropriate emergency service. If it does not 134 recognize the suffix (e.g., fire), it MUST forward the request to the 135 appropriate general emergency contact, handling it as if the address 136 was "sos". 138 It is beyond the scope of this document how the proxy determines the 139 appropriate public safety answering point or how it determines the 140 physical location of the SIP UA making the request. 142 TBD: Should something like sip:sos@localhost be supported, for SIP 143 phones that do not know which is the local domain? (Generally, SIP 144 UAs would determine this information via DHCP or inverse DNS lookup 145 of their IP address.) Alternatively, should a UA always use the AOR 146 domain if the UA knows that sos is supported "at home"? This avoids 147 that a non-sos-supporting local proxy bounces the request, but still 148 allows intercept by the outbound proxy. 150 4 Security Considerations 152 The SIP specification [2] details a number of security 153 considerations. Security for emergency calls has conflicting goals, 154 namely to make it as easy and reliable as possible to reach emergency 155 services, while discouraging and possibly tracing prank calls. It 156 appears unlikely that classical authentication mechanisms can be 157 required by emergency call centers, but SIP proxy servers may be able 158 to add identifying information. 160 5 Bibliography 162 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 163 levels," Request for Comments 2119, Internet Engineering Task Force, 164 Mar. 1997. 166 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 167 session initiation protocol," Request for Comments 2543, Internet 168 Engineering Task Force, Mar. 1999. 170 A. Vaha-Sipila, "URLs for telephone calls," Request for Comments 171 2806, Internet Engineering Task Force, Apr. 2000. 173 6 Acknowledgements 175 James Polk and Brian Rosen contributed helpful comments. 177 7 Authors' Addresses 179 Henning Schulzrinne 180 Dept. of Computer Science 181 Columbia University 182 1214 Amsterdam Avenue 183 New York, NY 10027 184 USA 185 electronic mail: schulzrinne@cs.columbia.edu