Internet Engineering Task Force (IETF) B. Rosen Request for Comments: 6881 NeuStar BCP: 181 J. Polk Category: Best Current Practice Cisco Systems ISSN: 2070-1721 March 2013 Best Current Practice for Communications Services in Support of Emergency Calling
AbstractThe IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6881. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................3 2. Terminology .....................................................3 3. Overview of How Emergency Calls Are Placed ......................3 4. Which Devices and Services Should Support Emergency Calls? ......4 5. Identifying an Emergency Call ...................................4 6. Location and Its Role in an Emergency Call ......................5 6.1. Types of Location Information ..............................6 6.2. Location Determination .....................................6 6.2.1. User-Entered Location Information ...................6 6.2.2. Access Network "Wire Database" Location Information .........................................6 6.2.3. End System Measured Location Information ............7 6.2.4. Network Measured Location Information ...............7 6.3. Who Adds Location? The Endpoint, or the Proxy? ............8 6.4. Location and References to Location ........................8 6.5. End System Location Configuration ..........................8 6.6. When Location Should Be Configured ........................10 6.7. Conveying Location ........................................11 6.8. Location Updates ..........................................11 6.9. Multiple Locations ........................................12 6.10. Location Validation ......................................12 6.11. Default Location .........................................13 6.12. Other Location Considerations ............................13 7. LIS and LoST Discovery .........................................13 8. Routing the Call to the PSAP ...................................14 9. Signaling of Emergency Calls ...................................15 9.1. Use of TLS ................................................15 9.2. SIP Signaling Requirements for User Agents ................16 9.3. SIP Signaling Requirements for Proxy Servers ..............17 10. Callbacks .....................................................18 11. Mid-Call Behavior .............................................19 12. Call Termination ..............................................19 13. Disabling of Features .........................................19 14. Media .........................................................20 15. Testing .......................................................21 16. Security Considerations .......................................22 17. IANA Considerations ...........................................22 17.1. Test Service URN .........................................22 17.2. 'test' Subregistry .......................................23 18. Acknowledgements ..............................................23 19. References ....................................................23 19.1. Normative References .....................................23 19.2. Informative References ...................................27
RFC3261] user agents, proxy servers, and Public Safety Answering Points (PSAPs) support emergency calling, as outlined in [RFC6443], which is designed to complement the present document in section headings, numbering, and content. Understanding [RFC6443] is necessary to understand this document. This Best Current Practice (BCP) succinctly describes the requirements of end devices and applications (requirements prefaced by "ED-"), access networks (including enterprise access networks) (requirements prefaced by "AN-"), service providers (requirements prefaced by "SP-"), and PSAPs to achieve globally interoperable emergency calling on the Internet. This document also defines requirements for "intermediate" devices that exist between end devices or applications and the access network. For example, a home router is an intermediate device. Reporting location on an emergency call (see Section 6) may depend on the ability of such intermediate devices to meet the requirements prefaced by "INT-". The access network requirements apply to those networks that may be used to place emergency calls using IETF protocols. Local regulations may impact the need to support this document's access network requirements. Other organizations, such as the National Emergency Number Association (NENA), define the PSAP interface. NENA's documents reference this document. RFC2119]. This document uses terms from [RFC3261], [RFC5012], and [RFC6443]. Section 5) from any other call by a unique service URN [RFC5031] that is placed in the call setup signaling when a home or visited emergency dial string is detected. Because emergency services are local to specific geographic regions, a caller must obtain his location (Section 6) prior to making emergency calls. To get this location, either a form of measuring (e.g., GPS) ([RFC6443] Section 6.2.3) device location in
the endpoint is deployed or the endpoint is configured (Section 6.5) with its location from the access network's Location Information Server (LIS). The location is conveyed (Section 6.7) in the SIP signaling with the call. The call is routed (Section 8) based on location using the Location-to-Service Translation (LoST) protocol [RFC5222], which maps a location to a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that serves a group of PSAPs. The call arrives at the PSAP with the location included in the SIP INVITE request.
ED-6/SP-5: Devices MUST be able to be configured with the home country from which the home dial string(s) can be determined. ED-7/SP-6: Emergency dial strings SHOULD be determined from LoST [RFC5222]. Dial strings MAY be configured directly into the device. AN-1: LoST servers MUST return dial strings for emergency services. ED-8: Endpoints that do not recognize emergency dial strings SHOULD send dial strings as per [RFC4967]. SP-7: If a proxy server recognizes dial strings on behalf of its clients, it MUST recognize emergency dial strings represented by [RFC4967] and SHOULD recognize the emergency dial strings represented by a tel URI [RFC3966]. ED-9: Endpoints SHOULD be able to have home dial strings provisioned. SP-8: Service providers MAY provision home dial strings in devices. ED-10: Devices SHOULD NOT have one-button emergency calling initiation. ED-11/SP-9: All sub-services for the 'sos' service specified in [RFC5031] MUST be recognized. RFC5222] is the Location Mapping Protocol defined by the IETF.
Section 6.2) supplied prior to receipt by the PSAP. RFC4119] and [RFC5139]. RFC6443] Section 6.2.2 for a discussion of how this value was determined.
AN-7/INT-6: Access networks and intermediate devices (including enterprise networks) that support intermediate range wireless connections (typically 100 m or less of range) and that do not support a more accurate location determination mechanism such as triangulation MUST support location configuration where the location of the access point is reflected as the location of the clients of that access point. AN-8/INT-7: Where the access network provides location configuration, intermediate devices MUST either be transparent to it or provide an interconnected client for the supported configuration mechanism and a server for a configuration protocol supported by end devices downstream of the intermediate device such that the location provided by the access network is available to clients as if the intermediate device was not in the path. RFC6443] Section 6 for a discussion of accuracy of location. ED-17/INT-9/AN-9: Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1 km accuracy) for the routing of calls. The location mechanism MAY be a service provided by the access network.
ED-21/INT-13: Devices MUST support both the Dynamic Host Configuration Protocol (DHCP) location options [RFC4776] [RFC6225] and HTTP-Enabled Location Delivery (HELD) [RFC5985]. When devices deploy a specific access network interface for which location configuration mechanisms such as Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device SHOULD support the additional respective access network specific location configuration mechanism. AN-13/INT-14: The access network MUST support either DHCP location options or HELD. The access network SHOULD support other location configuration technologies that are specific to the type of access network. AN-14/INT-15: Where a router is employed between a LAN and WAN in a small (less than approximately 650 square meters) area, the router MUST be transparent to the location provided by the WAN to the LAN. This may mean the router must obtain location as a client from the WAN and supply an LCP server to the LAN with the location it obtains. Where the area is larger, the LAN MUST have a location configuration mechanism satisfying the requirements of this document. ED-22/INT-16: Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location MUST be used. AN-15/INT-17: Access networks that support more than one LCP MUST reply with the same location information (within the limits of the data format for the specific LCP) for all LCPs it supports. ED-23/INT-18/SP-14: When HELD is the LCP, the request MUST specify a value of "emergencyRouting" for the "responseTime" parameter and use the resulting location for routing. If a value for dispatch location will be sent, another request with the "responseTime" parameter set to "emergencyDispatch" must be completed, with the result sent for dispatch purposes. ED-24: Where the operating system supporting application programs that need location for emergency calls does not allow access to Layer 2 and Layer 3 functions necessary for a client application to use DHCP location options and/or other location technologies that are specific to the type of access network, the operating system MUST provide a published API conforming to ED-12 through ED-23 and ED-25 through ED-32. It is RECOMMENDED that all operating systems provide such an API.
RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively. ED-27/INT-21: If the device sends a DHCPINFORM message, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as defined in [RFC4776], [RFC6225], [RFC5986], and [RFC5223], respectively. ED-28/INT-22: To minimize the effects of VPNs that do not allow packets to be sent via the native hardware interface rather than via the VPN tunnel, location configuration SHOULD be attempted before such tunnels are established. ED-29/INT-23: Software that uses LCPs SHOULD locate and use the actual hardware network interface rather than a VPN tunnel interface to direct LCP requests to the LIS in the actual access network. AN-16: Network administrators MUST take care in assigning IP addresses such that VPN address assignments can be distinguished from local devices (by subnet choice, for example), and LISs SHOULD NOT attempt to provide location to addresses that arrive via VPN connections unless they can accurately determine the location for such addresses. AN-17: Placement of NAT devices where an LCP uses an IP address for an identifier SHOULD consider the effect of the NAT on the LCP. The address used to query the LIS MUST be able to correctly identify the record in the LIS representing the location of the querying device. ED-30/INT-24: For devices that are not expected to change location, refreshing location on the order of once per day is RECOMMENDED.
ED-31/INT-25: For devices that roam, refresh of location information SHOULD be more frequent, with the frequency related to the mobility of the device and the ability of the access network to support the refresh operation. If the device detects a link state change that might indicate having moved, for example, when it changes access points, the device SHOULD refresh its location. ED-32/INT-26/AN-18: It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location, and systems SHOULD be designed such that the typical response time is under 100 ms. However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can be substantially improved over what can be obtained in 250 ms. RFC6442]. RFC6665] to the presence event [RFC3856]. For other location-by-reference schemes that do not support subscription, the PSAP will have to repeatedly dereference the URI to determine if the device moved. ED-38: If location was sent by value and the endpoint gets an updated location, it MUST send the updated location to the PSAP via a SIP re-INVITE or UPDATE request. Such updates SHOULD be limited to no more than one update every 10 seconds, a value selected to keep the load on a large PSAP manageable, and yet provide sufficient indication to the PSAP of motion.
Section 3 of [RFC5491]. ED-40: If an endpoint has more than one location available to it, it MUST choose one location to route the call towards the PSAP. If multiple locations are in a single Presence Information Data Format (PIDF), the procedures in [RFC5491] MUST be followed. If the endpoint has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable. SP-17: If a proxy inserts location on behalf of an endpoint and it has multiple locations available for the endpoint, it MUST choose one location to use to route the call towards the PSAP. If multiple locations are in a single PIDF, the procedures in [RFC5491] MUST be followed. If the proxy has multiple PIDFs and has no reasonable basis to choose from among them, a random choice is acceptable. SP-18: If a proxy is attempting to insert location but the endpoint conveyed a location to it, the proxy MUST use the endpoint's location for routing in the initial INVITE and MUST convey that location towards the PSAP. It MAY also include what it believes the location to be in a separate Geolocation header. SP-19: All location objects received by a proxy MUST be delivered to the PSAP. ED-41/SP-20: Location objects MUST be created with information about the method by which the location was determined, such as GPS, manually entered, or based on access network topology included in a PIDF-LO "method" element. In addition, the source of the location information MUST be included in a PIDF-LO "provided-by" element. ED-42/SP-21: A location with a method of "derived" MUST NOT be used unless no other location is available.
RFC6443]. SP-22: Proxies handling emergency calls MUST insert a default location in the INVITE if the incoming INVITE does not contain a location and the proxy does not have a method for obtaining a better location. AN-25/SP-23: Default locations MUST be marked with method=Default, and the proxy MUST be identified in a PIDF-LO "provided-by" element. RFC4119], the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO. ED-45/AN-26: To prevent against spoofing of the DHCP server, entities implementing DHCP for location configuration SHOULD use DHCPv4 message authentication [RFC3118] or DHCPv6 message authentication [RFC3315], although the difficulty in providing appropriate credentials is significant. ED-46: If S/MIME [RFC5751] is used, the INVITE message MUST provide enough information unencrypted for intermediate proxies to route the call based on the location information included. This would include the Geolocation header and any bodies containing location information. Use of S/MIME with emergency calls is NOT RECOMMENDED for this reason. ED-47/SP-24: Transport Layer Security (TLS) [RFC5746] MUST be used to protect location (but see Section 9.1). All SIP implementations of this specification MUST support TLS. RFC5389]. ED-49: Endpoints MUST support LIS discovery as described in [RFC5986] and LoST discovery as described in [RFC5223].
ED-50: The device MUST have a configurable default LoST server parameter. ED-51: DHCP LoST discovery MUST be used, if available, in preference to configured LoST servers. That is, the endpoint MUST send queries to this LoST server first, using other LoST servers only if these queries fail. AN-27: Access networks that support DHCP MUST implement the LIS and LoST discovery options in their DHCP servers and return suitable server addresses as appropriate. Section 6), it MUST use the cached value. ED-55: The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call. If it cannot obtain a new mapping quickly, it MUST use the cached value. If the device cannot update the LoST mapping and does not have a cached value, it MUST signal an emergency call without a Route header containing a PSAP URI. SP-25: Networks MUST be designed so that at least one proxy in the outbound path will recognize emergency calls with a Request URI of the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate that the endpoint understood the call was an emergency call. A proxy that processes such a call looks for the presence of a SIP Route header field with a URI of a PSAP. The absence of such a Route header indicates that the endpoint was unable to invoke LoST, and the proxy MUST perform the LoST mapping and insert a Route header field with the URI obtained.
SP-26: To deal with old user agents that predate this specification and with endpoints that do not have access to their own location data, a proxy that recognizes a call as an emergency call that is not marked as such (see Section 5) MUST also perform this mapping, with the best location it has available for the endpoint. The resulting PSAP URI would be placed in a Route header with the service URN in the Request URI. SP-27: Proxy servers performing mapping SHOULD use location obtained from the access network for the mapping. If no location is available, a default location (see Section 6.11) MUST be supplied. SP-28: A proxy server that attempts mapping and fails to get a mapping MUST provide a default mapping. A suitable default mapping would be the mapping obtained previously for the default location appropriate for the caller. ED-56/SP-29: [RFC3261] and [RFC3263] procedures MUST be used to route an emergency call towards the PSAP's URI. RFC4301] MAY be used instead of TLS for any hop. Either TLS or IPsec MUST be used when attempting to signal an emergency call. ED-58/SP-31: If TLS session establishment is not available or fails, the call MUST be retried without TLS. ED-59/SP-32: Following the procedures described in [RFC5626] is RECOMMENDED to maintain persistent TLS connections between entities when one of the entities is an endpoint. Persistent TLS connection between proxies is RECOMMENDED using any suitable mechanism. ED-60/AN-28: TLS SHOULD be used when attempting to retrieve location (configuration or dereferencing) with HELD. The use of the mechanism described in [RFC5077] is RECOMMENDED to minimize the time to establish TLS sessions without keeping server-side state. IPsec MAY be used instead of TLS. ED-61/AN-29: When TLS session establishment fails, the location retrieval MUST be retried without TLS.
RFC4967] with the dialed digits. 2. The To header field SHOULD be a service URN in the "sos" tree. If the device does not interpret local dial strings, the To: MUST be a dial string URI with the dialed digits. 3. The From header field SHOULD contain the address of record (AoR) of the caller. 4. A Route header field SHOULD be present with a PSAP URI obtained from LoST (see Section 8). If the device does not interpret dial plans or was unable to obtain a route from a LoST server, no such Route header field will be present. 5. A Contact header field MUST be globally routable, for example, a Globally Routable User Agent URI (GRUU) [RFC5627], and be valid for several minutes following the termination of the call, provided that the User Agent Client (UAC) remains registered with the same registrar, to permit an immediate callback to the specific device that placed the emergency call. It is acceptable if the UAC inserts a locally routable URI and a subsequent back-to-back user agent (B2BUA) maps that to a globally routable URI. 6. Other header fields MAY be included as per normal SIP behavior. 7. If a geolocation URI is included in the INVITE, a Supported header field MUST be included with a 'geolocation-sip' or 'geolocation-http" option tag, as appropriate [RFC6442]. 8. If a device understands the SIP location conveyance [RFC6442] extension and has its location available, it MUST include location as either location-by-value or location-by-reference, or both, according to the rules within RFC 6442. 9. An SDP offer SHOULD be included in the INVITE. If voice is supported, the offer SHOULD include the G.711 codec; see Section 14. As PSAPs may support a wide range of media types and codecs, sending an offerless INVITE may result in a lengthy return offer but is permitted. Cautions in [RFC3261] on offerless INVITEs should be considered before such use.
10. If the device includes location-by-value, the user agent (UA) MUST support multipart message bodies, since SDP will likely be also in the INVITE. Section 6.11). The location (in the signaling, obtained from a LIS, or default) MUST be used in a query to LoST with the service URN received with the call. The resulting URI MUST be placed in a Route header added to the call. 3. The proxy MAY add a Geolocation header field. Such an additional location SHOULD NOT be used for routing; the location provided by the UA should be used.
4. Either a P-Asserted-Identity [RFC3325] or an Identity header field [RFC4474], or both, SHOULD be included to identify the sender. For services that must support emergency calls from unauthenticated devices, valid identity may not be available. Proxies encountering a P-Asserted-Identity will need to pass the header to the PSAP, which is in a different domain. [RFC3325] requires a "spec(T)" to determine what happens if either the "id" privacy service or a Privacy header is present and requests privacy. In the absence of another spec(T), such proxies should pass the header unmodified if and only if the connection between the proxy and the PSAP is, as far as the proxy can determine, protected by TLS with mutual authentication using keys reliably known by the parties, encrypted with no less strength than AES, and the local regulations governing the PSAP do not specify otherwise. 5. Proxies SHOULD NOT return a 424 error. They should process the INVITE as best they can. 6. Proxies SHOULD NOT obey a Geolocation-Routing value of "no" or a missing value if they must query LoST to obtain a route. Emergency calls are always routed by location.
RFC3515]. Devices MUST react to such a transfer request with the appropriate INVITE. RFC3261] procedures for termination MUST be used for termination of the call. Section 14. ED-67/SP-39: The emergency dial strings SHOULD NOT be permitted in call forward numbers or speed dial lists. ED-68/SP-40: The user agent and proxies MUST disable call features that would interfere with the ability of callbacks from the PSAP to be completed, such as: o Do not disturb o Call forward (all kinds) These features SHOULD be disabled for approximately 30 minutes following termination of an emergency call.
ED-69: Callbacks SHOULD be determined by retaining the domain of the PSAP that answers an outgoing emergency call and instantiating a timer that starts when the call is terminated. If a call is received from the same domain and within the timer period, and it is sent to the URI in a Contact header or the AoR used in the emergency call, then it should be assumed to be a callback. The suggested timer period is 5 minutes. The mechanism described in [RFC4916] can be used by the PSAP to inform the endpoint of the PSAP's domain. Recognizing a callback from the domain of the PSAP will not always work, and further standardization will be required to give the endpoint the ability to recognize a callback. RFC3550]. ED-71: Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used. ED-72/SP-41: G.711 A-law (and mu-law if they are intended to be used in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711, a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and Adaptive Multi-Rate - WideBand (AMR-WB) in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding. ED-73: Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call. ED-74: Endpoints supporting Instant Messaging (IM) MUST support either [RFC3428] or [RFC4975]. ED-75: Endpoints supporting real-time text MUST comply with [RFC4103]. The expectations for emergency service support for the real-time text medium are described in [RFC5194] Section 7.1. ED-76: Endpoints supporting video MUST support H.264 per [RFC6184].
RFC6849] test and SHOULD support the "rtp-pkt-loopback" and "rtp-media-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User agents should expect the PSAP to loop back no more than 3 packets of each media type accepted (which limits the duration of the test), after which the PSAP would normally send BYE. ED-80: User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address not due to a reboot. After an initial test, a full test SHOULD be repeated approximately every 30 days with a random interval. ED-81: User agents MUST NOT place a test call immediately after booting. If the IP address changes after booting, the endpoint should wait a random amount of time (in perhaps a 30-minute period, sufficient for any avalanche-restart event to complete) and then test. ED-82: PSAPs MAY refuse repeated requests for test from the same device in a short period of time. Any refusal is signaled with a 486 (busy here) or 488 (not acceptable here) response.
RFC5069] and [RFC6280]. This document suggests that security (TLS or IPsec) be used hop by hop on a SIP call to protect location information, identity, etc. It also suggests that if the attempt to create a security association fails the call be retried without the security. It's more important to get an emergency call through than to protect the data; indeed, in many jurisdictions privacy is explicitly waived when making emergency calls. Placing a call without security may reveal user information, including location. The alternative -- failing the call if security cannot be established -- is considered unacceptable. RFC5031] for testing.
RFC5226]. The expert review should consider that the entries in this registry nominally track the entries in the 'sos' subregistry, although it is not required that every entry in 'sos' have an entry in 'test', and it is possible that entries in the 'test' subregistry may not necessarily be in the 'sos' subregistry. For example, testing of non-emergency URNs may be allowed. The reference is this document. The initial content of the subregistry is: Service Reference Description ------------------------------------------------------------------ test.sos RFC 6881 test for sos test.sos.ambulance RFC 6881 test for sos.ambulance test.sos.animal-control RFC 6881 test for sos.animal-control test.sos.fire RFC 6881 test for sos.fire test.sos.gas RFC 6881 test for sos.gas test.sos.marine RFC 6881 test for sos.marine test.sos.mountain RFC 6881 test for sos.mountain test.sos.physician RFC 6881 test for sos.physician test.sos.poison RFC 6881 test for sos.poison test.sos.police RFC 6881 test for sos.police [LLDP-MED] ANSI/TIA, "Link Layer Discovery Protocol - Media Endpoint Discovery", TIA Standard, TIA-1057, April 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [RFC4967] Rosen, B., "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier", RFC 4967, July 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010. [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010. [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011. [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011. [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012. [RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, February 2013.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)", RFC 5194, June 2008. [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011.