idnits 2.17.1 draft-schulzrinne-sipping-sos-03.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 126 has weird spacing: '....rescue amb...' == Line 127 has weird spacing: '....marine mar...' == Line 128 has weird spacing: '....police pol...' == Line 129 has weird spacing: '...ountain mount...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 6, 2002) is 7811 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 2806 (ref. '3') (Obsoleted by RFC 3966) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 draft-schulzrinne-sipping-sos-03.txt 6 December 6, 2002 7 Expires: May 2003 9 Emergency Services for Internet Telephony based on the Session 10 Initiation Protocol (SIP) 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines a universal emergency SIP URI, sip:sos@domain, 36 that allows SIP user agents to contact the local emergency number. It 37 also describes how such calls are routed for both PSTN and IP-based 38 emergency call centers. 40 1 Introduction 42 Using the PSTN, emergency help can often be summoned at a designated, 43 widely known number, regardless of where the telephone was purchased. 44 However, this number differs between localities, even though it is 45 often the same for a country or region (such as many countries in the 46 European Union). For end systems based on the Session Initiation 47 Protocol (SIP) [2], it is desirable to have a universal identifier, 48 independent of location, to simplify the user experience and to allow 49 the device to perform appropriate processing. Here, we define a 50 common user identifier, "sos", as the contact mechanism for emergency 51 assistance. 53 We also describe how such calls are routed to the appropriate 54 emergency call center (ECC). (In the United States and Canada, 55 emergency call centers are referred to as Public Safety Answering 56 Points (PSAPs).) Since each emergency call center is generally only 57 responsible for a specific geographic area, it is important that 58 calls are routed to the correct ECC. Regardless of whether the ECC is 59 connected to the PSTN or is directly reachable via SIP, the network 60 location of the caller has little relationship to its physical 61 location. If the call is routed through a PSTN gateway, the 62 originating number is likely either associated with the gateway or is 63 permanently assigned to the IP phone, regardless of where it is 64 currently located. For SIP-based ECCs, the IP address or Contact 65 header information in the call only provides crude approximation as 66 to the geographic location of the caller and may well be completely 67 wrong if virtual private networks are used. Thus, the SIP request 68 needs to convey the location of the caller so that the call can be 69 routed appropriately. Section 5 discusses one possible approach. 71 1.1 Terminology 73 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 74 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 75 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 76 indicate requirement levels for compliant SIP implementations. 78 2 Requirements 80 A single, global (set of) identifiers for emergency services is 81 highly desirable, as it allows end system and network devices to be 82 built that recognize such services and can act appropriately. Such 83 actions may include restricting the functionality of the end system, 84 providing special features, overriding user service constraints or 85 routing session setup messages. The details of the emergency service 86 and the associated end system and network server policies can be 87 specific to jurisdictions and are beyond the scope of this document. 89 3 Emergency URI 91 It is RECOMMENDED that SIP-based [2] end systems and proxy servers 92 support a uniform emergency call identifier, namely the user name 93 "sos" at any domain, e.g., 94 sip:sos@example.com 96 The host part of the emergency URI SHOULD be the host portion of the 97 address-of-record of the caller. 99 The domain-of-record was chosen since a SIP user agent may 100 not be able to determine the local domain it is visiting. 101 This also allows each user to test this facility, as the 102 user can ensure that such services are operational in his 103 home domain. An outbound proxy in the visited domain can 104 handle the call if it believes to be in a position to 105 provide appropriate emergency services. 107 In addition, user agents and proxies SHOULD also recognize the 108 telephone numbers 911 and 112, expressed as a "tel" URI [3,4] such as 110 tel:911;phone-context=+1 111 tel:112;phone-context=+1 113 for this purpose. Where feasible, user agents SHOULD recognize 114 additional, local emergency numbers. Outbound proxy servers MUST be 115 configurable to recognize additional local emergency numbers. 117 There are about 60 service numbers for emergency services 118 in the world; including them all is not practical, as that 119 would interfere with existing local two, three and four- 120 digit dialing plans. 122 In addition, we define subaddresses of sos for specific emergency 123 services: 125 sos.fire fire brigade 126 sos.rescue ambulance (rescue) 127 sos.marine marine guard 128 sos.police police (law enforcement) 129 sos.mountain mountain rescue 131 In some areas, these emergency services use different 132 numbers. 134 The "sos" user name and user names starting with "sos." MUST NOT be 135 assigned to any regular user. It is RECOMMENDED that SIP MESSAGE 136 requests are directed to a TTY-for-the-deaf translator or a short- 137 message service (SMS) if the emergency call center cannot handle SIP 138 messaging. 140 4 Request Handling 142 A user agent SHOULD direct an "sos" request to an outbound proxy 143 server. 145 Using a proxy server that is local to the user agent is 146 more likely to reach a geographically local server, 147 although that is not guaranteed if virtual private networks 148 are being used. 150 User agent servers and proxy servers MUST NOT require that the user 151 agent client be registered or authenticated in order to place an 152 emergency call. 154 OPTIONS requests to the user "sos" and the "sos.*" addresses 155 (sos.fire, etc.) can be used to test if the "sos" addresses are 156 valid. As in standard SIP, a 200 (OK) response indicates that the 157 address was recognized and a 404 (Not found) that it was not. Such 158 request cause no further action. It is RECOMMENDED that user agents 159 periodically automatically check for the availability of the "sos" 160 identifier and alert the user if the check fails. The period of such 161 automated checks SHOULD NOT be less than once per day and MUST be 162 randomly placed over the testing interval. 164 Any proxy, outbound or otherwise, that receives such a request MUST 165 forward (proxy) or redirect the request to the appropriate local 166 emergency number (e.g., 911 in the United States or 112 in Europe). 167 Typically, the proxy server routes the call to an appropriate PSTN 168 gateway, translating the request URI to the local emergency number. 169 Any SIP PSTN gateway shall translate this emergency identifier to the 170 locally supported emergency number. Determining the appropriate 171 number is discussed in Section 5. 173 If a proxy receives a "sos.*" request (such as sos.fire), the proxy 174 forwards it to the appropriate emergency service. If it does not 175 recognize the suffix (e.g., fire), it MUST forward the request to the 176 appropriate general emergency contact, handling it as if the address 177 was "sos". 179 5 Request Routing 180 Each SIP request directed to the emergency URI SHOULD contain 181 information about the caller's location. We outline a mechanism 182 below. 184 1. The SIP UA determines its location, preferably ahead of the 185 emergency call. It MAY use DHCP [5], retrieving the the 186 location either as geospatial coordinates (longitude, 187 latitude and altitude) [6] or as a civil address (street 188 and community) 190 The UA needs to inform the DHCP server about its network 191 attachment point. There are several possibilities, 192 including use of the RFC 3046 [7] Agent-Circuit-ID or 193 Remote-ID sub-options. This approach will only work if the 194 DHCP relay agent is colocated with the LAN device close to 195 the SIP UA. Another option, not yet fully supported, is to 196 have the UA determine the device and port information and 197 then include this in the DHCP request. There currently is 198 no DHCP option for doing so, however. 200 2. It then inserts this location into a SIP header field, for 201 example: 203 Location: ;lat=38.89868 ;long=-77.03723 ;alt=15 ;alt-unit=m 204 ;lares=0.000122 ;lores=0.000122 205 ;hno=600 ;lmk="White House" ;mcn="Washington" 206 ;stn="Pennsylvania" ;sts="Ave" ;sta="DC" 207 ;privacy=dnf 209 Here, we assume that the DHCP option provided a resolution 210 of 22 bits. The example is taken from [8]. 212 (The SIP header field format is fictitious and is defined 213 in TBD.) 215 Alternatively, the outbound proxy may map the UA's device 216 address to a physical location, e.g., based on a traceback 217 within an Ethernet switched LAN. Such mechanisms are beyond 218 the scope of this document. 220 3. The outbound proxy or recipient of the SIP request uses the 221 location information to determine the address of the 222 emergency call center. We call this entity the emergency 223 call router (ECR). The ECR needs to make a two-step 224 determination. First, it determines if the caller is local, 225 i.e., guaranteed to be served by the same ECC ("emergency 226 service area"). For example, this may be the case for an 227 ECR located on a corporate or university campus or a DSL 228 provider which precisely knows that a subset of its lines 229 are local to a ECC service area. If the caller is not 230 local, it needs to look up the serving ECC in a database. 231 The protocol for doing this lookup is currently not 232 standardized. 234 There are two basic decisions: 236 1. The ECC uses SIP-based technology, regardless of 237 location. In that case, the ECR simply proxies or 238 redirects the request to the SIP-capable ECC. Note 239 that the ECC can also be a front-end for a regional or 240 national call routing service that in turn finds the 241 correct emergency dispatch center. 243 2. The ECC uses traditional technology. Here, we have two 244 sub-cases: 246 1. The caller and ECR are known to be served by the 247 same ECC. In that case, the ECR places a normal 248 emergency call. 250 2. The caller and ECR are not in the same emergency 251 service area. In that case, a database lookup 252 determines the PSTN number of the ECC. The ECR 253 then routes the call to an appropriate PSTN 254 gateway that can place the call. Ideally, the 255 gateway may be local to the ECC, but that may not 256 be achievable, as it would require a gateway in 257 every community. 259 In the United States, for example, there are 260 about 5,000 primary emergency call centers, 261 called Public Safety Answering Points 262 (PSAPs). 264 In both of these cases, the ECR causes the calling 265 number to be a telephone number that is mapped by the 266 ECC to the location of the caller. (The process for 267 creating such mappings is beyond the scope of this 268 document. The process has been demonstrated in some 269 jurisdictions for multi-line telephone systems.) It is 270 not clear whether all circuit-switched trunk 271 technologies allow potentially arbitrary, out-of-area 272 calling numbers. 274 6 Alternative Identifiers Considered 276 The scheme proposed here follows the convention of RFC 2142 [9]. One 277 drawback is that it may conflict with locally assigned addresses of 278 the form "sos@somewhere". 280 There are a number of possible alternatives, each with their own set 281 of advantages and problems: 283 tel:sos This solution avoids name conflicts, but is not a valid 284 "tel" URI. It also only works if every outbound proxy knows 285 how to route requests to a proxy that can reach emergency 286 services. The SIP URI proposed here only requires a user's 287 home domain to be appropriately configured. 289 URI parameter: One could create a special URI, such as "aor- 290 domain;user=sos". This avoids the name conflict problem. 292 Special domain: A special domain, such as "sip:fire@sos.int" 293 could be used to identify emergency calls. This has similar 294 properties as the "tel:sos" URI, except that it is indeed a 295 valid URI. 297 7 Security Considerations 299 The SIP specification [2] details a number of security 300 considerations. Security for emergency calls has conflicting goals, 301 namely to make it as easy and reliable as possible to reach emergency 302 services, while discouraging and possibly tracing prank calls. It 303 appears unlikely that classical authentication mechanisms can be 304 required by emergency call centers, but SIP proxy servers may be able 305 to add identifying information. 307 Allowing the user agent to clearly and unambiguously identify 308 emergency calls makes it possible for the user agent to make 309 appropriate policy decisions. For example, a user agent policy may 310 reveal a different amount of information to the callee when making an 311 emergency call. Local laws may affect what information network 312 servers or service providers may be allowed or be required to release 313 to emergency call centers. They may also base their decision on the 314 user-declared destination of the call. 316 8 Normative References 318 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 319 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 321 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 323 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 324 initiation protocol," RFC 3261, Internet Engineering Task Force, June 325 2002. 327 9 Informative References 329 [3] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet 330 Engineering Task Force, Apr. 2000. 332 [4] H. Schulzrinne and A. Vaha-Sipila, "The tel URI for telephone 333 calls," Internet Draft, Internet Engineering Task Force, Oct. 2002. 334 Work in progress. 336 [5] R. Droms, "Dynamic host configuration protocol," RFC 2131, 337 Internet Engineering Task Force, Mar. 1997. 339 [6] J. Polk et al., "DHCP option for geographic location," Internet 340 Draft, Internet Engineering Task Force, Oct. 2002. Work in progress. 342 [7] M. Patrick, "DHCP relay agent information option," RFC 3046, 343 Internet Engineering Task Force, Jan. 2001. 345 [8] J. Polk et al., "Semantics for DHC location object within 346 GEOPRIV," Internet Draft, Internet Engineering Task Force, Oct. 347 2002. Work in progress. 349 [9] D. Crocker, "Mailbox names for common services, roles and 350 functions," RFC 2142, Internet Engineering Task Force, May 1997. 352 10 Acknowledgements 354 Andrew Allen, James Polk, Brian Rosen and John Schnizlein contributed 355 helpful comments. 357 11 Authors' Addresses 359 Henning Schulzrinne 360 Dept. of Computer Science 361 Columbia University 362 1214 Amsterdam Avenue 363 New York, NY 10027 364 USA 365 electronic mail: schulzrinne@cs.columbia.edu