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