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

[Francois Menard <[e-mail]>]

On 7-Aug-09, at 4:03 AM, Hannes Tschofenig wrote:

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

The ILECs here have committed to provide access to the MSAG, but they  
did not detail how the access would be provided.

What's important, is this be not the source of improv.  If CIVIC's are  
already pre-formatted in XML, them the ISP only has to cut and paste  
and send stuff to the ILEC SIP PROXY in the manner the proxy will  
dispatch for it being MSAG valid to begin with.

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

The interface of interest is not that of the ISP to AAA server, but  
rather that of the ILEC to ISP.

In the ILEC to ISP interface, there is no IP addresses travelling back  
and forth, just PPP session ID's and CIRCUIT-ID's and PPP user  
credentials with domain.

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


I actually want to say that the Access Network provider has to EMPOWER  
the ISP to do that.

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

Absolutely.

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

That's all stuff described here:

http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc

In those jurisdictions where the ILECs want to step up to the plate  
and take that much insofar as responsibility, this ENABLEs the  
simplified workflow as described here.

>
> 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?

No need. There is only ONE destination to choose for the ISP under the  
Canadian i2 proposal.

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

Under

http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc

This is what the ILECs propose in Canada


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

The PSAPs in Canada do  not accept interconnection from providers  
directly. You need to send them to the ILEC here...

F.


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

Merci beaucoup!

f.


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

Francois Menard
[e-mail]