[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Internet Engineering Task Force
Internet Draft                                               H. Schulzrinne
                                                             Columbia U.
May 28, 2002
Expires: July 2002

      Universal Emergency Address for SIP-based Internet Telephony


   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-

   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".

   The list of current Internet-Drafts can be accessed at

   To view the list Internet-Draft Shadow Directories, see


   This document defines a universal emergency SIP URI, sip:sos@domain,
   that allows SIP user agents to contact the local emergency number.

1 Introduction

   Using the PSTN, emergency help can often be summoned at a designated,
   widely known number, regardless of where the telephone was purchased.
   However, this number differs between localities, even though it is
   often the same for a country or region (such as many countries in the
   European Union). For SIP-based end systems, it is desirable to have a
   universal identifier, independent of location, to simplify the user
   experience and to allow the device to perform appropriate processing.
   Here, we define a common user identifier, "sos", as the contact
   mechanism for emergency assistance.

Schulzrinne                                                   [Page 1]

Internet Draft                    SOS                       May 28, 2002

1.1 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant SIP implementations.

2 Requirements

   A single, global (set of) identifiers for emergency services is
   highly desirable, as it allows end system and network devices to be
   built that recognize such services and can act appropriately. Such
   actions may include restricting the functionality of the end system,
   providing special features, overriding user service constraints or
   routing session setup messages. The details of the emergency service
   and the associated end system and network server policies can be
   specific to jurisdictions and are beyond the scope of this document.

3 Emergency URI

   It is RECOMMENDED that SIP-based [2] end systems and proxy servers     |
   support a uniform emergency call identifier, namely the user name      |
   "sos" at any domain, e.g.,                                             |

     sip:sos@example.com                                                  |

   The host part of the emergency URI SHOULD be the host portion of the   |
   address-of-record of the caller.                                       |

        The domain-of-record was chosen since a SIP user agent may   |
        not be able to determine the local domain it is visiting.    |
        This also allows each user to test this facility, as the     |
        user can ensure that such services are operational in his    |
        home domain. An outbound proxy in the visited domain can     |
        handle the call if it believes to be in a position to        |
        provide appropriate emergency services.

   In addition, user agents and proxies SHOULD also recognize the
   telephone numbers 911 and 112, expressed as a "tel" URI [3] such as
   tel:911 and tel:112, for this purpose. Where feasible, user agents
   SHOULD recognize additional, local emergency numbers. Outbound proxy
   servers MUST be configurable to recognize additional local emergency

Schulzrinne                                                   [Page 2]

Internet Draft                    SOS                       May 28, 2002

        There are about 60 short numbers for emergency services in
        the world; including them all is not practical, as that
        would interfere with existing local two, three and four-
        digit dialing plans.

   In addition, we define subaddresses of sos for specific emergency      |
   services:                                                              |

   sos.fire      fire brigade                                             |
   sos.rescue    ambulance (rescue)                                       |
   sos.marine    marine guard                                             |
   sos.police    police (law enforcement)                                 |
   sos.mountain  mountain rescue                                          |

        In some areas, these emergency services use different

4 Request Handling

   A user agent SHOULD direct such a request to a outbound proxy server,
   if configured, or send the request to the SIP multicast address if
   there is no outbound proxy server.

        Multicast offers additional robustness to visitors if
        firewalls prevent contacting the home domain and if the
        outbound proxy is configured by some non-DHCP means
        inaccessible to a visiting user.

   It is possible that there are several SIP proxies listening to the
   same multicast address, each routing the request independently to
   different emergency call centers. Proxies in such configurations MUST
   take steps to prevent this from occuring, for example to route the
   call based on the caller's identity or location. Determining and
   conveying the location of the caller is beyond the scope of this

        The multicast mechanism differs slightly from standard SIP
        processing; the use of an outbound proxy conforms to
        standard procedures. Multicast allows systems to make
        emergency calls with minimal configuration.

   Using a proxy server that is local to the user agent is more likely

Schulzrinne                                                   [Page 3]

Internet Draft                    SOS                       May 28, 2002

   to reach a geographically local server, although that is not
   guaranteed if virtual private networks are being used.

   The "sos" user name and user names starting with "sos." MUST NOT be
   assigned to any regular user. It is RECOMMENDED that SIP MESSAGE
   requests are directed to a TTY-for-the-deaf translator.

   User agent servers and proxy servers MUST NOT require that the user
   agent client be registered or authenticated in order to place an
   emergency call.

   For testing purposes, OPTIONS messages to the user "sos" and the
   "sos.*" addresses (sos.fire, etc.) SHOULD return an indication
   whether the address is defined, but cause no further action. It is
   RECOMMENDED that user agents periodically automatically check for the
   availability of the "sos"identifier and alert the user if the check
   fails. The period of such automated checks SHOULD NOT be less than
   once per day and MUST be randomly placed over the testing interval.

   Any proxy, outbound or otherwise, that receives such a request MUST
   forward (proxy) or redirect the request to the appropriate local
   emergency number (e.g., 911 in the United States or 112 in Europe).
   Typically, the proxy server routes the call to an appropriate PSTN
   gateway, translating the request URI to the local emergency number.
   Any SIP PSTN gateway shall translate this emergency identifier to the
   locally supported emergency number.

   If a proxy receives a "sos.*" request (such as sos.fire), the proxy
   forwards it to the appropriate emergency service. If it does not
   recognize the suffix (e.g., fire), it MUST forward the request to the
   appropriate general emergency contact, handling it as if the address
   was "sos".

   It is beyond the scope of this document how the proxy determines the
   appropriate public safety answering point or how it determines the
   physical location of the SIP UA making the request.

5 Alternatives Considered                                                 |

   The scheme proposed here follows the convention of RFC 2142 [4]. One   |
   drawback is that it may conflict with locally assigned addresses of    |
   the form "sos@somewhere".                                              |

   There are a number of possible alternatives, each with their own set   |
   of advantages and problems:                                            |

        tel:sos This solution avoids name conflicts, but is not really a  |

Schulzrinne                                                   [Page 4]

Internet Draft                    SOS                       May 28, 2002

             valid "tel" URI. It also only works if every outbound proxy  |
             knows how to route requests to a proxy that can reach        |
             emergency services. The SIP URI proposed here only requires  |
             a user's home domain to be appropriately configured.         |

        URI parameter: One could create a special URI, such as "aor-      |
             domain;user=sos". This avoids the name conflict problem.     |

        Special domain: A special domain, such as "fire@sos.int" could    |
             be used to identify emergency calls. This has similar        |
             properties as the "tel:sos" URI, except that it is indeed a  |
             valid URI.                                                   |

6 Security Considerations

   The SIP specification [2] details a number of security
   considerations. Security for emergency calls has conflicting goals,
   namely to make it as easy and reliable as possible to reach emergency
   services, while discouraging and possibly tracing prank calls. It
   appears unlikely that classical authentication mechanisms can be
   required by emergency call centers, but SIP proxy servers may be able
   to add identifying information.

7 Bibliography

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
   Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
   initiation protocol," RFC 3261, Internet Engineering Task Force, May

   [3] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet
   Engineering Task Force, Apr. 2000.

   [4] D. Crocker, "Mailbox names for common services, roles and
   functions," RFC 2142, Internet Engineering Task Force, May 1997.

8 Acknowledgements

   Andrew Allen, James Polk and Brian Rosen contributed helpful

9 Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science

Schulzrinne                                                   [Page 5]

Internet Draft                    SOS                       May 28, 2002

   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   electronic mail: schulzrinne@cs.columbia.edu

Schulzrinne                                                   [Page 6]