+---Location Request---+
                            |         (2)          |
                        +---V---+                  |
                        |  LIS  |                  |
                        +----+--+             +----+----+
                             |                |         |
                             +----Location--->|  Soft   |
 +--------+                          (3)      | Switch  |
 | Caller |------Call Initiation------------> |         |   
 +--------+          (1)                      +-+-^---+-+
                 +-------------+                | |   |
                 | LoST Server |<-Find Service--+ |   |        
                 +------+------+     (4)          |   |  
                        |                         |   |
                        +----------Service--------+   |
                                    (5)               |
                          +-----------+               |
                          | ESRP/PSAP |<------Call----+
                          +-----------+       (6)            
                                            

Figure 2: Softswitch-Centric Calling Model

In the softswitch-centric model when a VSP receives an emergency call it performs two tasks. The first task is to determine the correct LIS to ask for location information, this is done using a combination of reverse DNS lookup described in [RFC7216] to acquire the serving domain name and then using [RFC5986] to determine the LIS URI. Once the location is obtained from the LIS, the VSP determines the LoST server associated with the domain serving the caller and queries it for the correct PSAP address.

LoST server discovery is a domain based activity, similar to the LIS discovery technique. However, unlike the LIS that is a domain bound service, a LoST server is a geographically bound service. This means that for a domain that spans multiple geographic regions the LoST server determined may not be able to provide a route to the necessary PSAP. When this occurs, the contacted LoST server invokes the help of other LoST servers and this requires the deployment of forest guides.

At the time of writing, several countries have expressed their reluctance to deploy public LoST servers. In countries amenable to use of LoST and forest guides no public forest guides have been deployed. There appears little interest from the public sector in establishing a global forest guide network. These issues pose threats to both the device-centric and the softswitch-centric calling approaches in terms of them operating everywhere.

The device-centric and softswitch-centric calling models both involve the notion of a LIS bound to the serving access network. In many cases the LIS already knows the destination PSAP address for any given location. In [RFC6881] for example, the LIS validates all civic locations using a location validation procedure. This procedure is the same as a routing request and so the LIS has the resulting the PSAP routing information. In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider. Irrespective of the way in which the LIS learns the PSAP address for a location, the LIS will, in a great many cases, have this information.

This document specifies an extension to the HELD protocol so that emergency routing information can be requested from the LIS at the same time that location information is requested. The document updates [RFC6881] by requiring devices and softswitches that understand this specification to always request routing information to avoid the risk of query failure where no LoST server or forest guide network is deployed.

4. Mechanism

The mechanism consists of adding an element to the HELD locationRequest and an element to the locationResponse. The request element indicates that the requestor wants the LIS to provide routing information for the location where the device is. If the LIS understands the routing request and has routing information accessible it provides the information in a routingInformation element included in the locationResponse. How the LIS obtains this information is left to implementation, one possible option is that the LIS acquires it from a LoST server, other possibilities are described in Section 3.

A LIS that does not understand the routing request element ignores it and returns location as normal.

A LIS that does understand the routing request element but can’t obtain routing information returns location as normal.

The routing information in the location response consists of one or more service elements which is identified by a service name. The service name is a URI and might contain a general emergency service urn such as urn:service:sos or might contain a specific service urn. For each service name a list of one or more service destinations is provided. Each destination is expressed as a URI and each URI scheme should only appear once in this list. The routing information is intended to be used at the time it is received. To avoid any risks of using stale routing information the value should not be cached by the receiving entity.

Reusing the mapping element from the LoST findServiceResponse message to provide the routing information was considered. However, this would have meant that several of the mandatory components in the mapping element would have had to contain ambiguous or misleading values. Specifically, the "source" attribute is required to contain a LoST application unique string for the authoritative server. However, in the situations described in this specification there may not be an authoritative LoST server, so any value put into this attribute would be misleading. In addition to this, routing information received in the manner described in this specification should not be cached by the receiver, so detailing when the routing information expires or was last updated is irrelevant.

5. HELD Schema Extension

This section describes the schema extension to HELD.

<?xml version="1.0"?>
<xs:schema
  targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
  xmlns:xml="http://www.w3.org/XML/1998/namespace"
  elementFormDefault="qualified" attributeFormDefault="unqualified">

  <xs:element name="requestRoutingInformation">
     <xs:complexType name="empty"/>
  </xs:element>
  
  <xs:complexType name="service">
     <xs:complextContent>
       <xs:restriction base="xs:anyType">
       	  <xs:sequence>
       	     <xs:element name="dest" type="xs:anyURI"
       	          maxOccurs="unbounded"/>
       	  </xs:sequence>
       	  <xs:attribute name="serviceUri" type="xs:anyURI"
       	                use="required"/>
       </xs:restriction>
     </xs:complexContent>
  </xs:complexType>
    
  <xs:element name="routingInformation" type="ri:riType"/>
     <xs:complexType name="riType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element name="service" type="ri:service"
                        maxOccurs="unbounded"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
     </xs:complexType>

</xs:schema>

6. Examples

Figure 3 illustrates a <locationRequest> example that contains IP flow information in the request.

<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
		 responseTime="emergencyRouting">
	
	<requestRoutingInformation
	    xmlns=”urn:ietf:params:xml:ns:geopriv:held:ri"/>

	<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
	      layer4="tcp" layer3="ipv4">
	   <src>
	      <address>192.168.1.1</address>
	      <port>1024</port>
	   </src>
	   <dst>
	      <address>10.0.0.1</address>
	      <port>80</port>
	   </dst>
	</flow>
</locationRequest>

<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
      <locationUriSet expires="2006-01-01T13:00:00.0Z">
	<locationURI>
		https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
	</locationURI>
        <locationURI>
		sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
        </locationURI>
      </locationUriSet>
      
      <routingInformation
		xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
		<service serviceUri="urn:service:sos:police">
	      <dest>sip:nypd@example.com</dest>
		  <dest>sips:nypd@example.com</dest>
          <dest>xmpp:nypd@example.com</dest>
        </service>
        
        <service serviceUri="urn:service:sos:fire">
	      <dest>sip:fd@ny.example.com</dest>
		  <dest>sips:fd@ny.example.com</dest>
          <dest>xmpp:fd@ny.example.com</dest>
        </service>
      </routingInformation>
      
   </locationResponse>

BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>HELD Routing Information Extensions</title>
  </head>
  <body>
   <h1>Additional Element for HELD Routing Information</h1>
   <h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
     with the RFC number for this specification.]]
   <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
  </body>
 </html>
END