Re: [Ecrit] HUM on PhoneBCP

["Brian Rosen" <[e-mail]>]

This is indeed my problem with this discussion.

 

Current emergency call systems are nation-specific.  The goal, of nearly
everyone, is to make sure that devices sourced from anywhere, and visitors
with devices from anywhere, are able to make emergency calls anywhere.  

 

In order for that to happen, some things likely have to change.

 

I understand the argument for more network centric solutions.   The
underlying standards permit, and –phonebcp discusses, for example, proxy
query of the LoST server.  Proxy OBO for location is, as you know, on the
IETF agenda for completion in geopriv (HELD Identity).

 

But phone vendors need to have ONE solution that works everywhere.  It seems
to me that the way to do that is deploy a simple LoST server everywhere, and
follow phonebcp.  That would always work.  The cost of a LoST server for
Germany would be measured in tens of thousands of euros (you need 5-10
copies of a server with open source code, and a very small database that
doesn’t change very often).  That is a very inexpensive way to become
globally compliant with emergency call standards.  If your networks don’t
deploy DHCP/HELD, and the regulator is happy to force relationships between
access networks and calling networks, so that OBO becomes viable: fine.
Devices that are –phonebcp compliant will work.  And, when those devices
visit North America, they will also work.

 

I think it is extremely short sighted to ignore nomadic use, but if that is
what you want to do, that is your regulator’s choice.  However, the phone
MUST be capable of  doing the right thing if it were to be operated in North
America.  Even then, if it was, say, a mobile, and the 3GPP guys simply had
the E-CSCF do OBO with SUPL/MLP and the LoST query, then a current 3GPP
handset would be okay.  It’s not enough for North America (where I believe
IM from AOL on that handset also has to work), but it’s a start.

 

That does not change phonebcp.

 

Brian

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Dawson, Martin
Sent: Thursday, August 06, 2009 10:45 AM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [Ecrit] HUM on PhoneBCP

 

Hi Laura,

 

I regard it as a goal of ECRIT – as derived from the goals of the IETF
generally – to define a structure that will allow an Internet capable device
to connect to a network anywhere in the world and be able to make emergency
calls. Just as FTP, email protocols, SIP and etc. all work regardless of
which network the devices attach to. I don’t understand how the kind of
variations that you are requesting be added to the specification will allow
that to occur.

 

The position appears to be that the German regulator doesn’t require
anything – and the operators will not be proactive in following a
specification if it doesn’t include what already exists. In that context, I
don’t understand why there is a need for the BCP at all. There may be no
need to endorse it but, similarly, there should be no need to object to it –
since the operators will only put in place their preferred version of the
service in any case. That’s OK… insofar as it just means German networks
aren’t ECRIT compatible – “compatibility” isn’t a worthy goal in and of
itself; it has to actually mean any device can work anywhere.

 

Cheers,

Martin

 

  _____  

From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, 7 August 2009 12:29 AM
To: Dawson, Martin; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [Ecrit] HUM on PhoneBCP

 

Hi Martin, 

 

See comments inline [[LLi]].

 

 

Laura

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Dawson, Martin
Sent: Wednesday, August 05, 2009 11:00 AM
To: Jesske, Roland; [e-mail]
Subject: Re: [Ecrit] HUM on PhoneBCP

Hi Roland,

 

I think what you’re saying is that you don’t think that Germany will go on
to implement full ECRIT support but will peg development at an interim
phase. 
[[LLi]]  We don't know how the realtime application networks or EC will look
like in 20 years. Roland's answer only applies to the next 5 to 10 years. 

 

 That would be disappointing – not least because full ECRIT compliance would
ultimately decrease the overhead associated with emergency service support
for operators as well as providing a more universal service.

[[LLi]]  This may be true for "green field" ISPs and VSPs but not for
incumbent carriers with existing infrastructure.  And universal service is
not a requirement for us. Neither the German regulator requires it nor is it
a busines case.   

 

Nevertheless, I don’t think that decision invalidates the BCP; 
[[LLi]]  We think it does, because some of the requirements are not flexible
enough to cover the deployments within the next years.  The BCP should be
more flexible:  

*	Allow additional location identifiers 

*	Allow AN operated LOST

*	Provide a way to enable LOST-query based on national or
domain-specific location identifier. One posiblility is to allow the LIS to
query the LOST , but there are also other alternatives. 

*	Allow and describe also network-centric, not only ED-centric
architectures. If I  remember correctly, John Medland from BT also
recomended to use a more network- centric architecture, at least for the
next years. 

 

I think it just means that the German regulator and technical advisory
committees would point out the subset aspects of compliance that would be
applicable to that jurisdiction.  
[[LLi]]  Again, the draft is not flexible enough for it.  If the BCP
contains requirements which are not realistic, people will just discard the
BCP and implement proprietary stuff. My expectation from a standard body is
to define protocols and architecture which people are willing to implement
in their network or products , not only in the lab.

 

[[LLi]]  

We are not against the draft in principle. ECRIT provides  us with very
valuable specifications as LbyR, HELD, identity extensions. But targeting an
architecture which requires everbody to invest without a business case will
not help the draft in the end, also if it becomes a BCP.  It would make
sense to make it more flexible so people are willing to adopt it.    

 

 Actually, based on your description below, the NENA i2 architecture would
probably be a more straightforward baseline for analysis – as has been done
in the UK and Canada. Of course, it’s generally recognized as only an
interim step, even in those jurisdictions.

Other comments below.

 

Cheers,

Martin

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Wednesday, 5 August 2009 6:19 PM
To: [e-mail]
Subject: Re: [Ecrit] HUM on PhoneBCP

 

 

Dear all, 
We would like the document to become a BCP as soon as possible so the group
can move on with other documents related to emergency calling based on
location-by-reference and ED’s IP-address. 

[[MCD]] I think you might mean “identity extensions” rather than
location-by-reference because LbyR still requires the ED to obtain the
reference – e.g. by HELD.
[[LLi]] We use both, the IP-address as UE identity and LbyR. The SIP-proxy
uses the IP-address to query the LIS using HTTP (it's not HELD but SOAP over
HTTP, but anyway similar). The LIS responds with a numeric string associated
to the caller location, in principle a LbyR and with the PSAP number. The
proxy inserts the LbyR into the SIP-message (as P-Asserted-ID because the
PSAPs are in PSTN) and routes the message to the PSAP.  It's a low cost
solution. 

But we can not HUM for the current form of the document. 

Back to the document: Some requirements are far form being realistic, at
least in Germany, some are not realistic at all. Implementing these
requirements cost a carrier a lot of money and there is no ROI for it. 

Just a few examples: 

·       Requiring either geo or civic location does not provide carriers
with enough flexibility to reuse their existing mechanisms and location
databases. Routing of emergency calls is currently done in Germany based on
phone area code not on geo or civic location, at least for the fixed
network. For mobile networks the cell-id is used in common. This is
regulated by the german regulator. 

[[MCD]] How many unique PSAP routes are required in Germany? The US has lots
(6000 plus) and Australia has two (and they are redundant so it doesn’t
matter which one). Presumably geographic information, for PSAP catchment
areas, is the basis for determining which area codes are relevant to begin
with? After all, an area code is not intrinsically geographic; it’s a
network routing value. If so, then some geographic discriminator is already
in play in terms of constructing the area code based routing data (something
like zip codes perhaps?) – and in that case, it should be straightforward to
by-pass the area code step in the construction of routing that goes the
correct PSAP URI. 
[[LLi]] Currently, fixed networks carriers in Germany route the ECs based
only on the caller's area code. Sometime in the past, the carriers, the
regulator and the PSAPs operators (police, the Red Cross) agreed to do so.
This may change in the future, but it will take a quite long time.      

 With nomadic VoIP devices (and it’s no good being in denial about this
being the norm in the future) area code is no more reliable than it is for
conventional mobile phones. And, presumably, area code is not used for
conventional cellular emergency call routing?
[[LLi]]  As far as I know, mobile networks use the Cell-ID, not the area
code, and have a different table than the fixed network operators. They are
not going to change this.  As to the nomadic SIP-users...if we like it or
not, very few of our customers use our SIP service nomadic, let alone call
EC from their laptop.         

1              LOST as a national, let alone as a global directory is not
going to be implemented. The regulator will provide in the web a static
table which contains the PSAPs and the area for which they are responsible
(one or more area codes). Every carrier has to implement its own routing
database for emergency calls. 

[[MCD]] Whatever the carriers implement (and they have to implement
something) could just as readily be done using LoST. Then visiting devices,
with no association with any local VoIP proxy server would still be able to
determine a route to the correct PSAP. Alternatively, as long as the
regulator is maintaining a web service with the routing information, why not
make that directly accessible using LoST and save the operators the cost of
duplicating the service at all?
[[LLi]]  There is a big difference between maintaining a web page with a
table which operator can print and implement in their darabases and
operating a database which is queried for every emergency call in Germany,
must have an availablity of 99,99...% ,  is secure enough...you know. The
regulator will not do this.


2       We have no intention to rely on end devices for location information
because: 
·       ED provided location info is not trusted 

[[MCD]] Location by reference mitigates this trust issue. The emergency
network can (automatically and before human resources are engaged) assess
the source of the reference, and the validity of the location by
dereference, without having to trust location provided directly from the ED.
There are more sophisticated approaches to trustability even using LbyV –
based on digital signatures across appropriate attributes. This WG and
Geopriv haven’t really got to grips with that… yet.
[[LLi]]  We build the SIP-network and EC now. ED-provided location is needed
if EC must work for private and enterprise networks and VPNs.  We have no
such regulatory requirements.  And we don't know of any verdor of DSL-EDs
which provides today SIP with LbyR and is as cheap as the devices without
it. If you do, please let me know. 

The regulator ask us to guarantee that EC works. What if a customer dials
112 and his end device does not send the location? So I have to implement
both solutions, with and without ED provided location, anyway.  
1       There are already a lot of existing EDs in usage which don’t send
location.    

[[MCD]] Quite right. ECRIT doesn’t overly concern itself with that interim
situation. The UK and Canadian definitions for an interim solution (limiting
service to in-country VoIP proxy operators) both assume third-party query
via identity-extension to allow the proxy or the VPC to make the query to
the LIS. This isn’t extensible to universal emergency service access by all
visiting devices but it does put the necessary LIS functionality in place as
a very good starting point.  It would be a pity if Germany were to cease the
evolution there as it would not fulfil the real promise of the Internet and
the ECRIT model. 
[[LLi]]  I wonder who will drive and pay for upgrading the interim
solutions.  Unfortunatelly, it's all about money...

 Think about it; all the complexity of putting location determination
infrastructure in place for the purposes of dispatch is done – and then the
next, simpler step, of using that to support the routing procedure isn’t
taken… that would be a waste.

[[LLi]]  Do you think this is an argument for a product manager? They need a
business case.  

 

 

  We don’t intend to require our ED-vendors to provide location because it
is useless to us.   

We could agree with the document with following changes: 

*	Other location identifiers then geo or civil are allowed. It must be
possibe that the data foermat is flexible due to different requirements from
regulators over the whole world. (e.G Germany area codes for fixed- and
Cell-Id for moile- providers) 
*	The MUST for the end devices to support location information, DHCP
location options and HELD shall be removed 
*	It must be possible for the VoIP-provider’s proxy to use a LOST (or
an ESRP) provided by the AN or by other local provider on behalf of the AN.


 

 There is no value in Hum-ing documents which one is not going to implement
and does not fit into regulated schemes like in Germany. Currently, neither
the IETF- nor the 3GPP-architecture for emergency calling covers our real
needs for the next 2 to 5 years and in the end everybody still has its own
proprietary implementation.    

Best regards 

Roland 

 

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Roland Jesske
Gateways, Protokolle, Konvergenz, TE32-1
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
Postfach, 64307 Darmstadt (Postanschrift)
[phone] (Tel)
[phone] (Mobile)
E-Mail:  <mailto:[e-mail]> [e-mail] 
 <http://www.telekom.de/> http://www.telekom.de 

 

Registerrechtliche Unternehmensangaben:
Deutsche Telekom Netzproduktion (DT NP) GmbH
Aufsichtsrat: Timotheus Höttges (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis,
Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262 

 

 



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

 

 



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