[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09
How will address the millions of already deployed terminals and routers?
-----Original Message-----
From: ecrit-bounces at ietf.org on behalf of "François D. Ménard"
Sent: Tue 6/2/2009 9:36 AM
To: James M. Polk
Cc: ecrit
Subject: Re: [Ecrit] Emergency Call Framework for Canada;Questions on draft-ietf-ecrit-framework-09
See www.brisenet.net for my proposed architecture.
We're currently costing the modification of ISC DHCPD to support
Option 99 pass-through of PIDF-LO's and my ATA vendor is costing the
inclusion of DHCP Option 99 & SIP LOCATION CONVEYANCE in their end-
points, for submission to the CRTC in August.
f.
On 1-Jun-09, at 6:01 PM, James M. Polk wrote:
> John
>
> some comments in-line below
>
> At 02:25 PM 6/1/2009, John Lange wrote:
>> On April 15 2009, the Canadian Radio and Telecommunications
>> Commission
>> (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom
>> Notice of Consultation CRTC 2009-194".
>>
>> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm
>>
>> Paragraph 17 asks; "Are there alternative solutions that would
>> improve
>> on the current nomadic VoIP 9-1-1 service."
>>
>> The proposed architecture was developed by Bell Canada based very
>> loosely on NENAi2 with extensive modifications. As it was developed
>> by
>> the ILECs in 2006/2007, it does not employ the IETF standards.
>>
>> I am working on a submission to this proceeding which advocates the
>> implementation of the standards developed by the IETF's ECRIT working
>> group and it's members. (As a side note, if there are any
>> participants
>> on this list which are interested in helping with this effort,
>> please do
>> contact me.)
>>
>> After examining draft-ietf-ecrit-framework-09 and it's related RFCs
>> and
>> RFC-drafts, I have some specific questions/concerns which I hope this
>> list can answer.
>>
>> The Emergency Call Framework (ECF) as proposed :
>>
>> - Location is cached at end-point during boot/location discovery but
>> there does not appear to be any mechanism whereby the end-point
>> announces the success of this process to the SIP Registrar.
>
> This can be done with this specification:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-13.txt
>
>
>> If the device is able to determine it's location it should relay the
>> location information to the SIP registration server and the SIP
>> registrar should cache this information.
>
> The registrar caching geolocation is not a protocol issue, it's a
> configuration issue (once it receives the location from the
> endpoint). Notice this does not have to be with the first REGISTER
> request (meaning with a subsequent one), and/or it could be with
> each REGISTER request.
>
>
>> This allows the SIP Registrar and SIP proxy the ability to act
>> "on-behalf-of" end points that are not able to determine their
>> location
>> either because they are not location capable, or because they are not
>> able to determine location from their access provider.
>
> I'm missing what you mean by the starting "this" in the paragraph
> above?
>
> If the UA has its location, nothing needs to act "on-behalf-
> of" (OBO) it when sending location in any SIP request.
>
>
>> Furthermore, it removes the burden of "real-time" "on-behalf-of"
>> functionality from the rest of the network.
>
> If endpoints have their location (your original premise), OBO is
> unnecessary -- which further reduces network complexity, no?
>
>
>> The ability of the registrar to query and cache location data for
>> endpoints as opposed to the requirement to perform location
>> determination in real-time, has a dramatic impact on the technical
>> requirements of the overall solution.
>
> How is this better or easier or an optimization from the endpoint
> including its location in the SIP request in the first place?
>
>
>> If location data must be queried in real-time during an actual
>> emergency
>> event, the network components must be engineered to a much higher
>> standard. In some jurisdictions the mandated hardware and network
>> requirements will be impacted significantly. No less than redundant
>> five-nine hardware running on dedicated private networks will be
>> required resulting in higher costs.
>
> again, all this goes away if the endpoint has its location prior to
> placing the emergency call, then including this location information
> if more current location information cannot be discovered easily.
> Remember, unless you believe that everything needs to be built for
> mobile endpoints (i.e., those that actually move from room to room
> and from city to city with many times within the same day), being IP
> based doesn't mean endpoints move much. Further, given the fact
> that there are lower layer solutions already in place (802.11k and y
> and 3GPP) -- the IETF doesn't need to solve everything moving as if
> it was never where it is before. For example, my IP phones at home
> haven't moved all day (or all week, or all year, etc) -- therefore
> the location value they understand 1 minute ago, as well as a day
> ago, and a month ago haven't changed. This makes these locations
> valid for call routing and dispatch.
>
> Mobile nodes that are 3GPP based have their own way of tracking
> location changes.
>
> Mobile nodes that are 802.11 based will likely have a valid location
> for call routing at any time during the day, but dispatch could take
> a bit longer to determine. The good thing here is that most systems
> can determine location within 15 seconds for dispatch -- and I'd
> like to meet the dispatchers that can make it to their destination
> in time for that to be an issue ;-)
>
>
>> I submit that a query-and-cache methodology is more in line with the
>> spirit of other IETF protocols, the DNS system being a prime example.
>>
>> - Concerns with draft-ietf-geopriv-lis-discovery:
>>
>> The focus of LIS discovery seems to be on local access network
>> methods
>> such as DHCP and LLDP.
>>
>> DHCP & LLDP are not good choices for LIS discovery because they are
>> not
>> supported in the residential market. Residential firewall devices are
>> not likely to have DHCP/LLDP functionality and the likelihood that
>> these
>> devices will be replaced or upgraded is small.
>
> For LLDP, I fully agree with what you have above. I've had 4 ISPs
> over the last 10 years, and EACH of them have used DHCP, so I'm not
> sure where you get your data wrt DHCP not being supported in the
> residential market.
>
>
>> It would therefore seem that the emphasis should be on a LIS
>> discovery
>> mechanism that does not rely on the local network such as STUN + DNS.
>
> How many vendors in the residential market do you know of that
> implement STUN?
>
> It appears you keep getting back to a solution that requires an
> upgrade in the access networks or endpoints.
>
>
>> 1) Device determines its IP address by querying the STUN server.
>> 2) Device determines its domain name using reverse DNS.
>> 3) Device does LIS discovery via DNS (SRV/NAPTR).
>>
>> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on
>> behalf
>> of devices if: The proxy has a relationship with all access
>> networks the
>> device could connect to".
>>
>> This wording seems overly restrictive; in effect "all access networks
>> the device could connect to" amounts to every network on earth which
>> seems like an unreasonably high standard.
>>
>> How about:
>>
>> "Proxies MAY provide location on behalf of devices if: the device
>> does
>> not provide it's own location and the proxy is able to determine
>> location on-behalf-of the device.
>
> How does anyone know if this location OBO by the proxy is good
> enough for dispatch?
>
> I think (and this is just my opinion) that proxies in this situation
> will be just guessing where the endpoints are...
>
>
>> Any comments and/or questions would be welcome.
>>
>> Regards,
>> --
>> John Lange
>> http://www.johnlange.ca
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit at ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]