Re: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal

["Hannes Tschofenig" <[e-mail]>]

Hi Francois, 
 
Quick feedback below.

>Is anything wrong with the following E-9-1-1 workflow to be 
>possible with any ATA that can be upgraded to become Phone-BCP 
>compliant.
>
>Step 0) ISP is provided with a copy of the MASTER STREET 
>ADDRESS GUIDE already pre-formatted in PIDF-LO format.

This is not really necessary for the ISP to have. I suspect you want to
provide that information to the ISP since then he can do civic address
validation locally. The solution would still be OK by not having it locally
but rather maintained by someone else, such as the emergency services
network, in the spirit of NENA i2/i2.5, via LoST or some other mechanisms. 

Hence, I don't see this part as crucial for your solution. 

> ISP 
>provisions a DHCP server/ HELD server with a PIDF-LO object to 
>be associated with the IP address to be assigned to an 
>end-user based on the WIREMAP circut-ID.  In DSL wholesale, 
>the ISP uses the CIRCUT-ID acquired by RADIUS for a given 
>MSAG-VALID CIVIC PIDF-LO object.  The ISP then simply matches 
>the PPP username and password arriving on a given CIRCUIT-ID 
>to create a binding between the PUBLIC-IP associated 
>dynamically to the CIRCUIT-ID and the PIDF-LO object.  The ISP 
>really does not care about the PPP credentials.  All it wants 
>to do is BIND a PIDF-LO to a CIRCUIT-ID to an IP address and 
>allow for that PIDF-LO to be retrieved EITHER via HELD, or via 
>DHCP OPTION 99.
>
>For instance, ILECs for their L2TP LAC's are transitioning to 
>Juniper E320's - 8.2.3 patch-0.4 which is capable of the 
>following formats to pass along the unique DSLAM port to be 
>associated with a CIVIC address over RADIUS to the wholesale 
>ISP as described in 
>https://www.juniper.net/techpubs/en_US/junose10.0/information-p
>roducts/topic-collections/broadband-access/l2tp-calling-number-avp.html
>

The details of how the association of an IP address with location is done
very much depends on the specific deployment at the ISP. Some operators
might, for example, do IP address allocation within the AAA server and do
not run a separate DHCP server. Hence, the interaction between the DHCP
server and the AAA server becomes a local matter.   

So, in short you only want to say that the ISP has to provide the capability
to associate the IP address with location. 

>Step 1) In DSL wholesale, PPPoE will assign an IP.  The 
>reverse lookup would be done for this IP by the ATA.
>
>Step 2) If the ATA is behind nat, it would be provisioned with 
>a STUN server IP address.  The STUN server will return to the 
>ATA, what public IP address the ATA is behind.
>
>Step 3) The ATA would then perform an inverse lookup for that 
>IP address in the DNS server of that domain name, and would 
>expect there to be a DNS entry for 
>LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE-
>LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX
>

I guess that the previous 3 steps have the purpose of LIS discovery. Right? 
Maybe it would be good to say that. One could even provide example
references to documents, such as
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lis-discovery/ and
http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-02.txt




>Step 4) The ATA would then use its HELD stack to download the 
>location  object (PIDF-LO).

OK. 

>
>Step 5) ATA Memorizes PIDF-LO.

OK. 

>
>Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via 
>SIPCORE LOCATION CONVEYANCE (attached)

OK.

>
>Step 7) VoIP server provider will steer the call to the an 
>ILEC SIP PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 
>media gateway

You might want to provide some details on how this routing works and why the
ILEC runs the SIP proxy. There is no reason why this gatewaying cannot be
provided by someone else. 

For example, how would the VoIP provider figure out what proxy to send it? 
Would it have some "mapping database" in the style of LoST or the NENA i2
solution? 
Or: Would it use anycast, like the guys in Sweden want todo? 

This step is important and requires more description. 

>
>Step 8) ILEC will inspect the content of the PIDF-LO and will 
>route the call to the appropriate PSAP

Depending how you do 7 this step might be omittet. 

>
>All ILEC needs to do is to stop blocking the CIRCUIT-ID's over 
>the RADIUS accounting interface and accept to  implement a 
>SIP-based gateway + media gateway on the INTERNET which would 
>provide access to all the PSAPs the ILEC manages (which is the 
>case in Canada where PSAPs only interconnect directly with the 
>ILEC and no other competitors).

Why would you put this burden on the ILECs? I could imagine that PSAPs would
either accept direct VoIP calls from the VSP or would allow the VSPs to pick
their provider of choice for doing the VoIP-to-PSTN gatewaying when you have
to deal with legacy PSAPs. 

>
>I would appreciate answers by the end of the day on friday as 
>I am submitting this to the Canadian FCC (CRTC) friday evening.
>F.

Ciao
Hannes

>
>--
>Francois Menard
>[e-mail]
>
>
>
>
>Francois Menard
>[e-mail]
>
>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>