Re: [Ecrit] [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

[Brian Rosen <[e-mail]>]

Generally speaking, supporting emergency calls is not trivial.  There is a bunch of code to do that, even assuming that the device is already some kind of phone.  Please look at RFC6881.  What is deployed doesn’t exactly follow 68881, but it’s close.

The location MUST be validated before use.  It’s not enough to just use the RFC4776 civic address elements: it has to be a location the 9-1-1 system recognizes as valid.  There is a protocol (LoST, RFC5222) and a profile of PIDF-LO (nation specific) that has to be used to construct and validate the address.  These days, you also need Z (floor).  Generally, nearest hotspot isn’t adequate, especially if it’s on the wrong floor.  I wouldn’t say it’s totally wrong to use the location of the nearest hotspot, but that would be a fallback when whatever you use to reasonably accurately estimate location fails. 

We don’t use pANIs any more.  Also, that was US (or really US and Canada) specific.  There never was a “P-ANI” header.  We do use the SIP Geolocation header to carry the location.  The emergency system doesn’t “look up” a location any more.  The location is included in the signaling with the call.

Brian

> On Apr 18, 2023, at 11:26 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:
> 
> Hi Brian,
>  
> The use-case is about the device in the vicinity of a Wi-Fi hotspot which support emergency passpoint profiles. The device with the emergency passpoint profile, but with no specific access credentials to that hotspot, should be able to discover the network, perform an attach and complete access authentication to the IDP associated with the emergency realm. This will enable to the device to have internet connectivity with limited access for making emergency calls.
>  
> Passpoint profiles are widely supported by the device eco-system and so the definition of a new profile should not require any new code/development on the device. The aspects around network discovery, selection and association will still be based on the elements in the profile. The emergency profile can be installed at the time of manufacturing (requires rule making from the local regulator), or installed by the enterprise IT.
>  
> Location of the emergency caller is an important element in the system. The access point configured to support emergency calling will have to be configured with the location of the access point. When a device is permitted to attach to the network using the emergency passpoint profile, the access point will report RFC-5580 location elements, AP identifier and/or the secure location tag in the RADIUS signaling to the IDP.
>  
> The IDP will update these location elements and associate them to the access point (AP identifier and/or the Secure Location Tag).  The device making the emergency call will include these elements in the SIP P-ANI header. The emergency calling system will be able to look up the location from the IDP by using the elements in the P-ANI header. This allows the network to validate the device reported location with a trusted access point reported location. The reporting element, which is the access point, is a trusted network element with the OpenRoaming federation issued certificates and this provides an additional layer of validation of the caller reported location. This approach eliminates rogue calls with incorrect location in the SIP signaling.
>  
>  
> Regards
> Sri
>  
>  
>  
>  
>  
>  
>  
>  
> From: Brian Rosen <[e-mail]>
> Date: Tuesday, April 18, 2023 at 5:30 AM
> To: Sri Gundavelli <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
> Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>  
> I’m tempted to say “call me when the FCC does this”, but we’ll put that aside for now :)
>  
> This is the IETF, so when you say “FCC” you really need to say “the local regulator”.  You need to discuss how that actually works, especially when you are near borders.  you may have a hotspot connection in another country from the one that would provide emergency services,  
>  
> Are you assuming Internet connectivity everywhere here, so that the device can contact the voice service provider?  You should probably say that.
>  
> This is a fair amount of code on a device that would only be used in this very specific circumstance.  Lots of testing/certification.  Any ideas of how that would be done?  What is the incentive/imperative for a device mfg to make this work?
>  
> Are you aware of the “dispatchable location” issues?  Your location has to be dispatchable.  How are you getting that?
>  
>  
> Brian
> 
> 
>> On Apr 13, 2023, at 4:09 PM, Sri Gundavelli (sgundave) <[e-mail]> wrote:
>>  
>> Hi Brian,
>>  
>> On the second part of your question, few thoughts:
>>  
>> We are mainly targeting Wi-Fi hotspots supporting passpoint profiles. For example, taking the WBA’s OpenRoaming federation, there are identity providers, and access network providers, all part of the same roaming federation and with a legal framework between them. A user with a  given passpoint profile identifying a given RCOI (Roaming Consortium Id) will be able to latch on to any of the access network and complete access authentication.  IDP/RCOI policies are enforced on the session.
>>  
>> With the proposal, there will be IDP specific to the emergency realm and FCC will be the legal entity. FCC can authorize an MNO with the IMS network, or choose a voice service provider for supporting the emergency realm. When the user with emergency passpoint profile attaches to the hotspot support emergency profile, the authentication signaling from the Wi-Fi AP/hotspot will be terminated in the authentication server in the IDP, and the policies and configurations (including SIP service configuration)  associated with the emergency profile will be delivered to the device (IDP -> AN -> Device).  The device will complete SIP registration with the Proxy (obtained from the IDP).  So, to you question who is providing the SIP path, it is the entity designated by FCC and not the access network providing the voice services. The below diagram should provide some context of the environment.
>>  
>> The legal framework between ANP and IDP is an important aspect, as there will by now means to provide immunity to the ANP (with FCC as the IDP) against any call failures. We are thinking such legal provisions will improve the adoption of emergency calling by any access providers. This approach brings FCC into the equation; it helps promote the adoption.
>>  
>> You also talked about enterprise environment.  The above framework should technically work for enterprise use-case, including tele-worker use-cases. But as you point out we need to layout some considerations on the interconnect with the enterprise PBX and the emergency system. Some more thinking is needed here.
>>  
>>  
>>  
>> <image001.png>
>>  
>>  
>> Regards
>> Sri
>>  
>>  
>> From: Brian Rosen <[e-mail]>
>> Date: Thursday, April 13, 2023 at 10:12 AM
>> To: Sri Gundavelli <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <[e-mail]>, "Mark Grayson (mgrayson)" <[e-mail]>, ECRIT <[e-mail]>
>> Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>  
>> The emergency services are firmly against so-called “unitialiized devices”.  They are stuck with the regulatory requirement that has been put on the providers of such devices to support emergency calls, but they would be strongly against expanding the scope of such devices: there are roughly no cases of real emergency calls using such devices, and many, many cases of false emergency calls that cannot be traced to the caller.  I would strongly suggest you don’t pursue such an expansion of that requirement.  It’s a bad idea, and it doesn’t do what proponent’s hoped it would do.  We have substantial real world experience.
>>  
>> You need a reliable identity that can be traced to a real person.  It’s never ironclad (pre-paid cellular for example), but it has to work most of the time.
>>  
>> I’m still confused who the entity that is providing the SIP path is supposed to be.  Are you expecting the WiFi access point owner to do that or some mobile network operator?  If it’s the WiFi AP owner, then they don’t have an interconnect in most cases: they might have a PBX on that network with a PSTN interconnect (like a SIP Trunk) that supports emergency calling, but that’s fairly far removed from the WiFi network and assuming they will allow a random WiFi user to connect to their AP, and then provide a SIP path to emergency services seems very far fetched to me.
>>  
>> But if it was some kind of mobile network operator, what relationship do they have with the enterprise that has the AP?
>>  
>> Callbacks require identity: see above
>>  
>> Brian
>>  
>> 
>> 
>> 
>>> On Apr 13, 2023, at 11:25 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:
>>>  
>>> Hi Brian,
>>>  
>>> Thanks for the follow-up. These are very good comments. In the revised version, we will capture all these points.
>>>  
>>> On the requirement around interconnect to emergency network, we are thinking the FCC designated entity providing identity and voice services for the realm, “sos.fcc-authorized.org <http://sos.fcc-authorized.org/>” will be able to meet the requirements, and the interconnect will be similar to how any MNO’s IMS interconnect is realized today. We will analyze this and add some text.
>>>  
>>> On traceability comment, the current cellular systems allow emergency call from a device with an expired SIM subscription, or no SIM card. At least in some countries this is allowed. Most GSM phones allow calling of emergency numbers without a SIM card, 112, 911, 118, 000, 110, 08, and 999. Calling these numbers will force the device to use any available network. I need to check the call flow if there is exchange of IMEI, but AFAIK there is no traceability there. In the proposal we have we require the use of emergency passpoint profile, it is possible to signal device specific identifiers in the signaling, and that is one way to realize device traceability. We already have mechanisms for location traceability. But, this allows traceability to a device, not to a person. Mark may have some additional thoughts here.
>>>  
>>> On the call backs, once the device is able to perform SIP registration with the emergency SIP proxy, it will be possible to support the callbacks. Will analyze this in detail.
>>>  
>>> Regards
>>> Sri
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> From: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>> Date: Wednesday, April 12, 2023 at 4:36 PM
>>> To: Sri Gundavelli <[e-mail] <mailto:[e-mail]>>
>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Christer Holmberg <[e-mail] <mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail] <mailto:[e-mail]>>, ECRIT <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>  
>>> <moving to ecrit>
>>> Some entity has to connect to the emergency network (in North America and EU Next Gen systems, this is the “Emergency Services IP Network” or ESInet.  Although the standards say that calls must be accepted over the Internet, in practice all current implementations have direct interconnect between the originating service provider and the ESInet.  If it’s an IMS network operator, they have such connections, and would use their E-CSCF.  I think it’s pretty unlikely that they would support a non-IMS call path.  But there has to be some OSP.  It could be an enterprise, as long as the enterprise permitted access, had a reasonable authentication system tied to some kind of identity and a SIP proxy server.
>>>  
>>> The emergency authorities don’t like unauthenticated calling sources.  That is how we get swatting.  So your proposal has to describe what identity is, and how that’s traceable to a real person.  You also have to describe how we do call-backs to the caller.
>>>  
>>> Brian
>>> 
>>> 
>>> 
>>> 
>>>> On Apr 4, 2023, at 1:38 PM, Sri Gundavelli (sgundave) <[e-mail] <mailto:[e-mail]>> wrote:
>>>>  
>>>> HI Roland,
>>>>  
>>>> Thank you for your comment.
>>>>  
>>>> I agree,  if IMS is unavailable P-CSCF/E-CSCF will all be unavailable.  The key point is non-availability of the cellular network, for PDU creation and/or accessing emergency voice functions. This goes back to Christer’s comment suggesting to use non-IMS terminology.  We will work on that.
>>>>  
>>>> On your other comment, access to IMS for wired/wireline devices with IMS-only subscription is a possibility. But we still need to allow the device to connect to the available hotspot with no access-network credentials and be able to obtain the IMS configuration. The IMS network in question can be based of a generic IETF defined voice function, which can do call routing to the PSAP. If a MNO is willing to let their IMS network be available for wired and non-cellular devices, that is an option.
>>>>  
>>>> Once the device gets connectivity to the access network based on the special emergency passpoint profile, the access network can deliver the associated IMS/voice-service configuration options to the device. The realm that we are proposing sos.fcc-authorized.org <http://sos.fcc-authorized.org/> and associated IDP can be configured with the IMS/voice-service configuration. These IMS/voice-service functions can be from an MNO, or some other service provider that FCC will authorize.
>>>>  
>>>> These configuration options will be signaled from the IDP to the access network, and in turn will be delivered it to the device over DHCP/ND/802.11. The device can perform registration with those voice functions and can initiate the emergency call. 
>>>>  
>>>> Regards
>>>> Sri
>>>>  
>>>>  
>>>>  
>>>>  
>>>> From: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Date: Tuesday, April 4, 2023 at 12:44 AM
>>>> To: Sri Gundavelli <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: AW: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>>  
>>>> Hi,
>>>> What does this mean that IMS is unavailable? 
>>>> When IMS is unavailable also the Emergency service (E-CSCF) is unavailable.
>>>>  
>>>> Did you also discover the IMS Access possibilities with Digest, where you have an IMS Subscription w/o any RAN connectivity and only via wireline/WIFI?
>>>>  
>>>> Best Regards
>>>>  
>>>> Roland
>>>>  
>>>> Von: dispatch <[e-mail] <mailto:[e-mail]>> Im Auftrag von Sri Gundavelli (sgundave)
>>>> Gesendet: Montag, 3. April 2023 16:56
>>>> An: Christer Holmberg <christer.holmberg=[e-mail] <mailto:christer.holmberg=[e-mail]>>; Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>>> Cc: [e-mail] <mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail] <mailto:[e-mail]>>
>>>> Betreff: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>>  
>>>> Hi Christer,
>>>>  
>>>> Yes, 3GPP does define the interworking architecture with Wi-Fi, where the UE can use Wi-Fi to reach 3GPP core network for PDU establishment. The scenario that we have and what FCC CSRIC 8 looked into is where H-PLMN/V-PLMN and IMS is unavailable. Also, the interworking procedures assume there is Wi-Fi access connectivity. The access network in question may not have any relation to the operator for the UE to perform SIM based authentication to the access network.
>>>>  
>>>> The UE may not even have a cellular modem or SIM/eSIM credentials. What are trying to enable is allow the device to use a special emergency passpoint profile for connecting to any of the available hotspots that support emergency calling services. The device may be Wi-Fi only or a dual-radio capable device. Furthermore, if I see the carrier documentation for Wi-Fi calling, it requires the user to configure a civic address prior making any emergency call, and which a caller in distress may never configure. We are addressing this issue, by allowing a trusted access network with the federation issued certificates to signal the location over RADIUS to the IDP/CLF, which the network can cross correlate with the reported location in the SIP signaling.
>>>>  
>>>> <image001.png>
>>>>  
>>>> Regards
>>>> Sri
>>>>  
>>>>  
>>>> From: Christer Holmberg <christer.holmberg=[e-mail] <mailto:christer.holmberg=[e-mail]>>
>>>> Date: Monday, April 3, 2023 at 3:21 AM
>>>> To: Sri Gundavelli <[e-mail] <mailto:[e-mail]>>, Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: RE: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>>  
>>>> Hi,
>>>>  
>>>> Note that 3GPP has defined emergency calls over WiFi, so please indicate how your draft relates to that work.
>>>>  
>>>> Regards,
>>>>  
>>>> Christer
>>>>  
>>>> From: dispatch <[e-mail] <mailto:[e-mail]>> On Behalf Of Sri Gundavelli (sgundave)
>>>> Sent: Saturday, 1 April 2023 4.53
>>>> To: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>>> Cc: [e-mail] <mailto:[e-mail]>; Mark Grayson (mgrayson) <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>>  
>>>> Hi Brian,
>>>>  
>>>> Sure. Will move the discussion to ECRIT. 
>>>>  
>>>> Thanks for the pointers to the LoST and PIDF-LO work. Will add some considerations on how devices capable of LoST can obtain location-specific service configuration.
>>>>  
>>>> LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.
>>>>  
>>>> Ok. We will analyze this. If the mechanisms around Location-validity also covers the cases around detecting rogue/compromised clients, beyond making sure the claimed civic address exists, it will be very useful know. Will add the considerations.
>>>>  
>>>> The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.
>>>>  
>>>> Ok. Thanks for the pointers. Will add these considerations.
>>>>  
>>>>  
>>>> Regards
>>>> Sri
>>>>  
>>>> From: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>>>> Date: Friday, March 31, 2023 at 11:05 AM
>>>> To: Sri Gundavelli <[e-mail] <mailto:[e-mail]>>
>>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
>>>>  
>>>> I do think discussion on this draft should move to ecrit.
>>>>  
>>>> Obtaining the regulatory specific calling service configuration (including the numbers) is defined in LoST (RFC5222).
>>>> The location must be provided in PIDF-LO form (RFC4119 and its updates).  That is the form (at least the actual location information part) that you use to query the LoST server to get the configuration data and the form of the data you  send to the emergency services.
>>>> LoST also provides the mechanism to validate location (which you do at configuration time) to make sure the location you send is known by the emergency services.
>>>> The text has to say how the device uses the location it discovers to make a call (‘perform”), which is what RFC6881 describes.  There are some practical differences in how NG9-1-1 and NG1-1-2 actually work that has to be taken into consideration when looking at 6881.
>>>>  
>>>> Brian
>>>>  
>>>>  
>>>> 
>>>>> On Mar 31, 2023, at 4:55 PM, Sri Gundavelli (sgundave) <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>  
>>>>> Hi Brian,
>>>>> 
>>>>> Thanks a lot for reviewing the document. I agree, the document should provide the larger emergency calling context. The current art, the elements in the system, interfaces with the PSAPs and other touch points. We are familiar with the prior efforts in IETF and also standards bodies including 3GPP and around ATIS reports. Perhaps a discussion on how NG911/NG211 emergency service network are deployed will be useful. The document requires more work, and this is just a starting point. 
>>>>> 
>>>>> The key technical objective for this work is around enabling a Wi-Fi capable device to be able to discover hotspots that support emergency calling, ability to perform a network attach, be able to obtain the regulatory-domain specific calling voice service configuration (including emergency calling numbers) and be able to perform the emergency call. The focus is also on how the network can obtain the location of the emergency caller and the mechanisms for detecting rogue device signaling incorrect location.  Finally, some considerations on the emergency passpoint profiles that are required to be present on the device. This work complements the prior IETF efforts on emergency support for greatly improving the access to emergency services. There are tens of thousands of Wi-Fi hotspots supporting Wi-Fi roaming based on passpoint standards. This approach allows the devices to be able to use any of those hotspots for making that emergency call. 
>>>>> 
>>>>> On the choice of the draft title, we do understand the emergency calling numbers are specific to the regulatory domain in question and the proposed approach is not specific to any one regulatory domain. In that sense, we should have been bit more sensitive about this. We will modify the draft title to be generic and not specific to one regulatory domain.
>>>>> 
>>>>> Thanks a lot for the feedback.
>>>>> 
>>>>> Regards
>>>>> Sri
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/31/23, 2:02 AM, "Brian Rosen" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> I have read this draft.
>>>>> 
>>>>> 
>>>>> It is totally lacking context of current and evolving standards in emergency calling, including:
>>>>> 1. Basic IETF emergency calling standards (/RFC4119/RFC5222/RFC5985/RFC6881)
>>>>> 2. NG911 and NG112 standards that are being deployed, which are based on the IETF standards
>>>>> 3. ETSI and ATIS standards that support the above
>>>>> 
>>>>> 
>>>>> While I don’t know enough about WiFi or some of the 3GPP standards to comment on the technical approach in the doc, I am intimately familiar with what is deployed, and about to be deployed in emergency calling and this doc can’t begin to get considered until it deals with the issues associated with the IETF/NENA/EENA/ETSI/ATIS work.
>>>>> 
>>>>> 
>>>>> As a really simple start, authors might consider that 9-1-1 is North America only, while the IETF is world-wide.
>>>>> 
>>>>> 
>>>>> Brian
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mar 27, 2023, at 12:35 AM, Sri Gundavelli (sgundave) <sgundave=[e-mail] <mailto:sgundave=[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Dear All:
>>>>>> 
>>>>>> Attached is the link to the document on Supporting emergency 911 services over Wi-Fi. The attached document proposes an approach based on WBA's Wi-Fi OpenRoaming and uses many other elements which are already in standards. 
>>>>>> 
>>>>>> We are looking for some technical feedback. We believe there is value in IETF identifying new methods for improving e911 service access.
>>>>>> 
>>>>>> Appreciate any feedback.
>>>>>> 
>>>>>> Regards
>>>>>> Sri
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Name: draft-gundavelli-dispatch-e911-wifi
>>>>>> Revision: 00
>>>>>> Title: Emergency 911 Services over Wi-Fi
>>>>>> Document date: 2023-03-13
>>>>>> Group: Individual Submission
>>>>>> Pages: 15
>>>>>> URL: https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt&gt;>
>>>>>> Status: https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/ <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/&gt;>
>>>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi&gt;>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Abstract:
>>>>>> Proposed is an approach for supporting emergency 911 services over
>>>>>> IEEE 802.11 based Wi-Fi access networks. This approach leverages the
>>>>>> legal framework and the building blocks of the OpenRoaming federation
>>>>>> for extending emergency 911 calling support to already deployed tens
>>>>>> of thousands of OpenRoaming Wi-Fi hotspots. The proposal addresses
>>>>>> the key issues in emergency calling, around discovery and
>>>>>> authentication to access network supporting emergency services,
>>>>>> emergency access credentials, location determination of the emergency
>>>>>> caller, and delivering emergency voice service configuration to the
>>>>>> device and call routing.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The IETF Secretariat
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>