Subject: Re: [Ecrit] HUM on PhoneBCP

From: <[email-masked]>
Date: Wed, 5 Aug 2009 10:18:32 +0200

> 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. 
> 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. 
> 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. 
> 2	We have no intention to rely on end devices for location information because: 
> ·	ED provided location info is not trusted 
> 1	There are already a lot of existing EDs in usage which don> '> t send location.    
>   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) 
> +496151 628 2766 (Tel)
> +491718618445 (Mobile) 
> E-Mail: [email-masked] 
> 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
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 5 Aug 2009 03:59:51 -0500

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

Nevertheless, I don't think that decision invalidates the BCP; 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. 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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, 5 August 2009 6:19 PM
To: [email-masked]
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.

Just a few examples: 

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

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

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

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

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

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

Best regards 

Roland 

E-Mail: [email-masked] <mailto:[email-masked]>  

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

---

From: <[email-masked]>
Date: Thu, 6 Aug 2009 16:29:02 +0200

Hi Martin, 
 
See comments inline [[LLi]].

Laura

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Dawson, Martin
	Sent: Wednesday, August 05, 2009 11:00 AM
	To: Jesske, Roland; [email-masked]
	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

	 

	Dear all, 

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

	Just a few examples: 

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

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

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

	Best regards 

	Roland

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 6 Aug 2009 09:44:42 -0500

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 7 August 2009 12:29 AM
To: Dawson, Martin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP

Hi Martin, 

 

Laura

	Hi Roland,

	

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

	[[LLi]]  

	Other comments below.

	Cheers,

	Martin

	 

	Dear all, 

	Just a few examples: 

	

	Best regards 

	Roland

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 6 Aug 2009 10:20:54 -0500

I neglected to do a point by point, sorry. So - that follows:

Cheers,

Martin

Hi Martin, 

 

Laura

	Hi Roland,

	[[MCD]] The implementation of the LIS function is the most significant aspect for operators - and that needs to happen in short term scenarios in any case. The provision of LoST can be a national asset/service. The provision of PSAP URIs is an emergency service responsibility. Those are the key requirements - and that does provide a framework that will work into the next 20 years and beyond.

	[[MCD]] I think this is only true to the same extent that a pure Internet green field ISP only has to worry about Internet trunk connectivity and doesn't have to worry about PSTN circuit trunk connectivity. The latter infrastructure is legacy and not particularly applicable to the Internet component of the service. Providing ECRIT emergency calling support requires the addition of a LIS, access to LoST (whoever hosts it), and a route to the PSAP URI(s). Both types of operator need to do that. Whatever switched circuit legacy emergency infrastructure already exists in the established operator needs to continue to exist to support the emergency calls on that access.

	[[MCD]] Agreed - although that can be done by local-specific use of fields in the PIDF-LO based on jurisdictional convention and be appropriately parsed by LoST in that jurisdiction in a quite transparent fashion. A German technical advisory committee could make this recommendation within that jurisdiction without deference to the BCP and without impact to ECRIT-compliant devices.

	*	Allow AN operated LOST

	[[MCD]] I don't think the BCP excludes the possibility of the access network hosting LoST. It shouldn't - since this is a jurisdictional decision. As long as the LoST service can be discovered/used when attached to the access, it shouldn't matter where it is hosted.

	[[MCD]] I was in favour of the LIS proxying the LoST request - since they both share a "locality" it simplifies the whole discovery plot. However, that didn't take hold in the debate so we have what we have. Given that - a LIS still need only provide the national level location (i.e. DE) in the PIDF-LO if that's all that's required to make a successful LoST query. The rest can be done using LbyR - with the LIS also providing the reference along with the coarse location. Doesn't that satisfy the requirement?

	[[MCD]] I don't really understand this "X-centric" argument. Even traditional cellular architectures require a combination of end device and network capabilities. Maybe if you are being specific you mean; there should be no ECRIT-specific requirements on the end device (though I'm not sure why ECRIT should have this rule when other architectures don't). You're right John M did propose such an approach. Not to put words in his mouth, but this was in the context of an interim architecture - per my comments below on the Canada and UK interim approaches. It works in the limited scope of devices having to proxy calls through "national" VoIP carriers - it doesn't meet the long term vision of ECRIT. An interim architecture, by definition, is not the end-game architecture. ECRIT only seeks to define the end-game; there are already interim architectures to choose from - which was my point about suggesting it might be better to baseline off i2 for the time being rather than trying to shoehorn interim constraints into ECRIT.

	[[MCD]] What I mean is that compliance isn't compulsory. It's OK to say "we have decided to deviate from the specification in this way".

	[[LLi]]  

	[[MCD]] Lots of the elements you mention exist outside of the BCP - LbyR, HELD, identity extensions... they aren't defined by the BCP and can be used in any other context. The BCP has a very specific goal of defining a way that emergency calls can be made by any Internet connected device/proxy anywhere that follows the specification; it doesn't seek to be more than that - which I think is what you're looking for. As I say, check out the interim recommendations by the CRTC in Canada and NICC in the UK.

	Other comments below.

	Cheers,

	Martin

	 

	Dear all, 

	Just a few examples: 

	

	Best regards 

	Roland

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 6 Aug 2009 19:10:19 +0300

Hi Martin, 
 
you provided a very useful response. 
 
A few minor notes below: 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dawson, Martin
	Sent: 06 August, 2009 18:21
	To: [email-masked]; [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Ecrit] HUM on PhoneBCP

	Cheers,

	Martin

	Hi Martin, 

	 

	Laura

		Hi Roland,

		[Hannes] This is absolutely correct. Particularly for fixed networks there is often no LIS available and hence it requires additional cost. It is also quite unlikely that you will come up with a business model of selling the fixed location of the subscriber for non-emergency services purposes. There is, however, no reason for network operator to ask for financial support from the government (and we see this happening in various places throughout the world). In the long run it will be quite difficult to get away  without having a LIS provided by the access provider. Everyone understands that transition time needs some time. This is what other emergency services organizations, such as NENA and others,  are looking into.

		So, there is no reason to be so negative towards this work.  

		

		[Hannes] Regarding additional overhead: This is a fairly broad claim and generic claim that will be hard to justify. Some notes that come to my mind when it comes to overhead and performance. We have visited the police PSAP in Vienna/Austria and no location support was provided for cellular calls. Guess how much delay that causes for the overall performance of emergency services. I also saw how emergency services organizations structure change as they move towards Next Generation emergency services and the consequence was a far less complex structure and I expect further simplifications that will be incorporated as we move along. 

		[Hannes] As part of the efforts currently being done in EENA we hope to provide a recommendation of how to use civic addresses within each member state, similar to what has been excercised with http://www.ietf.org/id/draft-ietf-geopriv-civic-address-recommendations-03.txt and also being done by NENA for the US. 

		If those investigations will lead to the conclusion that new fields are required then we will ask for more or figure out how to accomplish the functionality. 

		*	Allow AN operated LOST 

		[Hannes] As Martin said it is possible for AN to operator a caching LoST server (it will most likely not be an authoritative LoST server, I believe). There are different deployment models and the protocol is flexible with this regard. Phone BCP cannot mandate a specific deployment approach as we already know that there will be different stories in different parts of the world.  

		[Hannes] We indeed discussed this aspect and the conclusion was to not proxy LoST in HELD. Reducing the number of options reduces the implementation complexity and lowers the cost for implementation. 

		The fact that we do not have support for this functionality specified and not referenced in PhoneBCP does not mean that it will not be proposed in the future and might find excitement.  

		[Hannes] Martin captured it quite nicely. I have in meetings also stated that it would be good for this group to also describe and discuss intermediate deployment architecture. We got blocked with the completion of PhoneBCP and Framework but we might still look into some of these aspects in the future. We also have to consider that NENA has been working on a transition architecture, namely NENA i2/i2.5 as mentioned (which also uses many building blocks from ECRIT or at least semantically similar mechanisms). Since many of these transition architectures are very much focused on national systems it is likely that we might find difficulties to generalize them in a way that it still remains useful. Since there are many legacy components in the game the IETF might not be the right place todo this type of overall architecture work. 

		Please also note that while we see countries looking at these transition architectures, particularly when they have to deal with legacy PSAPs not supporting IP, we also see a large number of countries switching to a next generation architecture from an emergency services network point of view since 

		a) they have to update their PSAPs anyway (because new signaling protocols are being added) and only the audio part remains unchanged. 

		b) they get many benefits and cost reducts from moving to IP. 

		[Hannes] From what I hear from the regulator is that you are taking the first steps already to move into a direction that goes into an architecture that distributes PSAP boundaries to make routing of emergency calls by VoIP providers possible. With a few minor enhancements you will quickly end up with an architecture utilized, for example, in Sweden or as envisioned by Lithuania. 

		[[LLi]]  

		[Hannes] We understand that the business model, I call it funding model, for emergency services is complicated. There are places in the world where interesting funding models are being found. I believe that Phone BCP does not require a lot of additional investments from access network providers particularly if they do not provide voice/application servers. We additionally put the burden for these operators as low as possible. I believe that sharing of responsibilities in the IETF ECRIT architecture is much better than it can found in any of the other architectures I have seen. We could discuss these aspect in more detail if there is interest. 

		Other comments below.

		[Hannes] The NENA i2 architecture (or better a modified version) would be more interesting for a comparison. Please note that there is an ongoing effort to update NENA i2 (to i2.5) by updating some of the work that is being done elsewhere (such as in the IETF) so that you have up-to-date protocols. You might find a number of concepts in there that are familiar. From a network operator point of view the only difference is the ability to deal with legacy end points that do not have obtained location. This is, however, also included in the PhoneBCP even though it is treated as a failure case there. An architecture that has to deal with legacy end points also has to deal with a number of weaknesses. Looking forward to have end points that may not have obtained location but a reference to location to ensure robut location lookup might not put a too huge burden on the involved parties with a lot of increased robustness of the overal system. These software updates to obtain these LbyRs could be judged impossible by some but then I would also like to know how software bugs are being dealt with without doing any software updates.  

		Ciao

		Hannes

		Cheers,

		Martin

		 

		Dear all, 

		Just a few examples: 

		

		Best regards 

		Roland

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Aug 2009 12:20:55 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Dawson, Martin
Sent: Thursday, August 06, 2009 10:45 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
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

  _____  

Hi Martin, 

 

Laura

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dawson, Martin
Sent: Wednesday, August 05, 2009 11:00 AM
To: Jesske, Roland; [email-masked]
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 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: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, 5 August 2009 6:19 PM
To: [email-masked]
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. 

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.   

*	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)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail:  <mailto:[email-masked]> [email-masked] 
 <http://www.telekom.de/> http://www.telekom.de 

Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis,
Klaus Peren

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]

---

From: John Lange <[email-masked]>
Date: Thu, 06 Aug 2009 13:42:50 -0500

On Wed, 2009-08-05 at 03:59 -0500, Dawson, Martin wrote:
>  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.

Lest anyone get the wrong idea, NENAi2 has not been "done in Canada".

Only a "Canadian i2" has been suggested (not approved or implemented)
and for the most part it resembles NENAi2 only in that they both contain
"i2" in the title.

Canadian i2 has similar names for the functional elements and interfaces
even though many of those elements are missing or operate completely
differently than NENA i2.

Most importantly, Canadian i2 is not compatible with phone-bcp or
ecrit-framework nor would it be an interim stepping-stone to any
"next-gen" solution for many reasons but not the least of which is the
fact that it does not allow location aware devices.

-- 
John Lange
http://www.johnlange.ca

---

From: John Lange <[email-masked]>
Date: Thu, 06 Aug 2009 14:15:31 -0500

On Thu, 2009-08-06 at 12:20 -0400, Brian Rosen wrote:
> 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.

I was originally quite sceptical about bcp and framework (which you can
read in my previous posts to this list) because:

 - it relies on DHCP to relay location to endpoints
 - relies on endpoints to be location aware
 - does not specify any mechanism for OBO

All of these things mean it's very unlikely it will be implemented in
any regulatory jurisdiction any time soon.

However, I'm now in favour of the document(s) for the reason that I've
finally seen Brian put into words:

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

That is the absolute critical point!

Since OBO can not be implemented without forced compliance in each
regulatory jurisdiction, it should be left up to each jurisdiction. 

Hopefully the geopriv group will get something completed for OBO and
then the various regulators will have something "standards based" to
implement OBO on.

So just to reiterate:

Step 1: a standard that will work everywhere (someday)

Step 2: various standards that bridge the gap between today and someday

This is the source of a lot of conflict and confusion because regulators
want Step 2 first but you can't build a bridge if you don't know where
the other side is.

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Aug 2009 12:23:31 -0700

> fact that it does not allow location aware devices.

Can you unpack what "does not allow location aware devices" means?
Do you mean that the location awareness in devices is not presumed,
or that location from end stations are not trusted, or something else?

regards,

Ted

---

From: John Lange <[email-masked]>
Date: Thu, 06 Aug 2009 14:38:37 -0500

> or that location from end stations are not trusted, or something else?

There is no part of Ci2 which allows location to be obtained (v0) or
transmitted (v1) from endpoints.

In NENAi2 terms, there is no v0 or v1 interface in Ci2.

To answer your question, not only is "location awareness in devices ...
not presumed", it is presumed that:

- devices are not location aware and never will be.
- and, VSPs can not do and will never do sip-location-conveyance.

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Aug 2009 15:51:13 -0400

> fact that it does not allow location aware devices.
In NENA i2, the way we did it is to say that the VPC looks for location asserted on the call. If it sees it, use that.  If it doesn't, use the database it has.  That makes it upwards compatible with i3 location, and allows -phonebcp compliant phones to be introduced while i2 is still deployed.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 6 Aug 2009 18:10:16 -0500

Hi John,

That is why I chose my words carefully to say "recommended" and
"proposed" and to attempt to clarify that each jurisdiction baselined
off i2 - not that they use i2 in toto. In fact i2 prefers
location-capable devices as well - so these jurisdiction-specific
recommendations are, by necessity, variants on that architecture.
Further, i2 incorporates the same dependence on VoIP providers doing the
proxying and a necessary relationship between them and the emergency
network in the form of the VPC and ESGW network elements. It
incorporates the same sorts of national-specific constraints that drive
these interim variants; that's why it's a useful baseline for these
national interim solutions.

Most of the variation is in terms of how the access to application
network associations are determined. The mechanics of ensuring a source
IP address is preserved and able to be associated back to an ISP/LIS for
the OBO step is a cat that can be skinned in many ways. Advisory
committees in different places spend a significant amount of their time
working on that aspect.

The nice thing about ECRIT, once you accept that an ECRIT compliant
terminal (I don't like the term "phone" at all - we're really talking
about computers these days) can have emergency calling embedded at the
operating system level. There's no need for operators to take
responsibility for that aspect any more than they take responsibility
for the implementation of web browsers. There's no longer a need to
invest the time and effort in "cat skinning" mentioned above. In fact,
I'd suggest that jurisdictions (and operators) could save a lot of
investment by deciding to go directly to ECRIT/i3. It's tough in, say,
the US where there are thousands of devolved PSAPs that have to be
IP-enabled. In jurisdictions with a more centralized call center
architecture and management, it should be possible to get to ECRIT
compliance more quickly than implementing interim solutions.

How about we consider the possibility that a migration to ECRIT-capable
devices (based on a standard reference implementation of an emergency
call client) may actually be able to appear quite quickly? This is
likely to happen before most regulators even get their head around VoIP.

You say these interim solutions don't permit location aware devices. I
think you mean they don't rely on them - but location aware devices can
still exist. By the time a LIS is implemented to support OBO, it already
has the majority of the functionality it needs to support target client
queries. That's a small incremental change to implementation. So I posit
that these interim architectures do represent a quite sensible stepping
stone toward ECRIT compliance.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of John Lange
Sent: Friday, 7 August 2009 4:43 AM
To: [email-masked]
Subject: Re: [Ecrit] HUM on PhoneBCP

On Wed, 2009-08-05 at 03:59 -0500, Dawson, Martin wrote:
> 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.

-- 
John Lange
http://www.johnlange.ca

_______________________________________________
Ecrit mailing list
[email-masked]
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]

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 6 Aug 2009 18:16:05 -0500

The "never will" parts seem a bit gratuitous. Personal preference
perhaps - but, as I say, I think it's a simple step to move from an
OBO-only LIS to an ECRIT-compliant LCP LIS. So the "never will" part
seems a rather dogmatic position.

What happens when, in fact, devices start incorporating ECRIT clients as
a matter of course...? I think Canada is innovative; it's likely to want
to take advantage of that development and enable the benefit of
ubiquitous emergency services via all devices/access... I would have
thought.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of John Lange
Sent: Friday, 7 August 2009 5:39 AM
To: Ted Hardie
Cc: [email-masked]
Subject: Re: [Ecrit] HUM on PhoneBCP

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 7 Aug 2009 09:36:50 +0200

You said:

As I say, check out the interim recommendations by the CRTC in Canada and NICC in the UK.

There is no such thing as interim recommendations from UK NICC.

There is a document under development. Whatever it currently says has no status as a UK NICC document. The last I heard the document was under substantial reediting.

regards

Keith

Sent: Thursday, August 06, 2009 4:21 PM

I neglected to do a point by point, sorry. So – that follows:

Cheers,
Martin

Hi Martin,

Laura

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.
[[MCD]] The implementation of the LIS function is the most significant aspect for operators – and that needs to happen in short term scenarios in any case. The provision of LoST can be a national asset/service. The provision of PSAP URIs is an emergency service responsibility. Those are the key requirements – and that does provide a framework that will work into the next 20 years and beyond.

 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.
[[MCD]] I think this is only true to the same extent that a pure Internet green field ISP only has to worry about Internet trunk connectivity and doesn’t have to worry about PSTN circuit trunk connectivity. The latter infrastructure is legacy and not particularly applicable to the Internet component of the service. Providing ECRIT emergency calling support requires the addition of a LIS, access to LoST (whoever hosts it), and a route to the PSAP URI(s). Both types of operator need to do that. Whatever switched circuit legacy emergency infrastructure already exists in the established operator needs to continue to exist to support the emergency calls on that access.

 *   Allow additional location identifiers
[[MCD]] Agreed – although that can be done by local-specific use of fields in the PIDF-LO based on jurisdictional convention and be appropriately parsed by LoST in that jurisdiction in a quite transparent fashion. A German technical advisory committee could make this recommendation within that jurisdiction without deference to the BCP and without impact to ECRIT-compliant devices.

 *   Allow AN operated LOST
[[MCD]] I don’t think the BCP excludes the possibility of the access network hosting LoST. It shouldn’t – since this is a jurisdictional decision. As long as the LoST service can be discovered/used when attached to the access, it shouldn’t matter where it is hosted.

 *   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.
[[MCD]] I was in favour of the LIS proxying the LoST request – since they both share a “locality” it simplifies the whole discovery plot. However, that didn’t take hold in the debate so we have what we have. Given that - a LIS still need only provide the national level location (i.e. DE) in the PIDF-LO if that’s all that’s required to make a successful LoST query. The rest can be done using LbyR – with the LIS also providing the reference along with the coarse location. Doesn’t that satisfy the requirement?

 *   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.
[[MCD]] I don’t really understand this “X-centric” argument. Even traditional cellular architectures require a combination of end device and network capabilities. Maybe if you are being specific you mean; there should be no ECRIT-specific requirements on the end device (though I’m not sure why ECRIT should have this rule when other architectures don’t). You’re right John M did propose such an approach. Not to put words in his mouth, but this was in the context of an interim architecture – per my comments below on the Canada and UK interim approaches. It works in the limited scope of devices having to proxy calls through “national” VoIP carriers – it doesn’t meet the long term vision of ECRIT. An interim architecture, by definition, is not the end-game architecture. ECRIT only seeks to define the end-game; there are already interim architectures to choose from – which was my point about suggesting it might be better to baseline off i2 for the time being rather than trying to shoehorn interim constraints into ECRIT.

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.
[[MCD]] What I mean is that compliance isn’t compulsory. It’s OK to say “we have decided to deviate from the specification in this way”.

[[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.
[[MCD]] Lots of the elements you mention exist outside of the BCP – LbyR, HELD, identity extensions… they aren’t defined by the BCP and can be used in any other context. The BCP has a very specific goal of defining a way that emergency calls can be made by any Internet connected device/proxy anywhere that follows the specification; it doesn’t seek to be more than that – which I think is what you’re looking for. As I say, check out the interim recommendations by the CRTC in Canada and NICC in the UK.

 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

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.

Just a few examples:

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

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

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

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

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)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: [email-masked]<mailto:[email-masked]>
http://www.telekom.de<http://www.telekom.de/>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 7 Aug 2009 03:10:26 -0500

Last I heard it should be published shortly.

I'm not sure what you're getting at. I was referring Laura to the (draft or whatever) interim recommendation as a useful piece of work to consider with respect to the German situation. Are you suggesting it's not useful and/or will not actually be published?

Cheers,

Martin

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Friday, 7 August 2009 5:37 PM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP

You said:

regards

Keith

	Cheers,

	Martin

	Hi Martin, 

	 

	Laura

		Hi Roland,

		

		*	Allow AN operated LOST 

		[[LLi]]  

		Other comments below.

		Cheers,

		Martin

		 

		Dear all, 

		Just a few examples: 

		

		Best regards 

		Roland

---

From: [email-masked]
Date: Fri, 7 Aug 2009 09:16:57 +0100

> Last I heard it should be published shortly.

Indeed - the NICC document has been through some major re-editing but is 
due to be re-submitted to the working group's parent committee for 
approval very shortly. 

Ray

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 13:58:56 +0200

Hi Martin,  

Hi Laura,

	[[LLi]] This is fine and usefull. Just that every country uses today different formats for the location used for emergency calls. Changing this will take time and costs money. 

	What is the harm in allowing ECs to work with local location formats which are understood only by the LIS and the PSAP ?. I dont see why a common location format must be implemented by everybody. 

	Maybe the EC could work like this : 

	*	The proxy discovers the LIS based on EDs IP-address using reverse-DNS and SRV record (this is possible with "identity extenssions")

	*	It retrieves the location ( e.g. using HELD) in a local format understood only by the LIS and the PSAP, which are in the same country. The location is just a string which is passed transparently through the network to the PSAP. In my opinion, it would be in principle  posible to use LbyR to transport local location identidfiers, e. g.  [email-masked] , but this is currently my personal opinion, I didn' found any statemant or example in the drafts.   
		
	*	The LIS delivers, together with the LbyR above, the PSAP URI.  As far as I know there is currently no way to do this in HELD (or did I miss something?).        

	It would be an alternative which is interoperable and quite easy to implement, without the need for the operators to change their location databases. I think by allowing this scenario, interoperable EC could be achieved earlier. And this does not exclude the scenario described in the framework and phone-bcp, where the EDs retrieve deo or civic location, which is needed for EC to work in private/enterprise networks.  

	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. 
	[[LLi]]  This is not quite true. We have to ensure that EC works for different AN- and VoIP-provider and for nomadic users in Germany by 2013. Our current solution does not allow this and there is the same for other carriers. We definitively need to define in Germany an architecture which fullfills this requirements. It would be very usefull if we can use standard protocols. But nobody will be willing to change everything at once.  Having a standard based architecture which is low cost would be a great advantage. 

	Kind regards

	Laura     

	 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

	Hi Martin, 

	 

	Laura

		Hi Roland,

		

		*	Allow AN operated LOST 

		[[LLi]]  

		Other comments below.

		Cheers,

		Martin

		 

		Dear all, 

		Just a few examples: 

		

		Best regards 

		Roland

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 14:12:28 +0200

Hi Martin, 
 
NENA i2 is not an international standard.  We can not use it as a reference. Also, in Germany, there is no dedicated for the emergency service infrastructure (or money for building one) like you have in the US or a central PSAP like in UK. This is quite important.  
 
People here will not agree to use NENA as a reference. 

Kind Regards

Laura

	From: Dawson, Martin [mailto:[email-masked]] 
	Sent: Friday, August 07, 2009 10:10 AM
	To: DRAGE, Keith (Keith); Liess, Laura; Jesske, Roland; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Ecrit] HUM on PhoneBCP

	Cheers,

	Martin

	You said:

	regards

	Keith

		Cheers,

		Martin

		Hi Martin, 

		 

		Laura

			Hi Roland,

			

			*	Allow AN operated LOST 

			[[LLi]]  

			Other comments below.

			Cheers,

			Martin

			 

			Dear all, 

			Just a few examples: 

			

			Best regards 

			Roland

---

From: [email-masked]
Date: Fri, 7 Aug 2009 13:18:23 +0100

> The proxy discovers the LIS based on EDs IP-address using reverse-
> DNS and SRV record (this is possible with "identity extenssions")

Laura,

Please see draft-thomson-geopriv-res-gw-lis-discovery-02

The main LIS Discovery draft from Geopriv previously did almost exactly 
what you've just described, but it was changed because of complaints from 
the DNS folk (myself included) that it assumed a mapping between domain 
names and network access that simply often doesn't exist.

The current proposal instead simply stores the LIS Discovery U-NAPTR 
records directly in the reverse DNS tree, where there's a much stronger 
(almost 100%) mapping between the DNS and the network access provider.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 7 Aug 2009 07:38:41 -0500

Hi Laura,

It's not necessary to normatively reference i2 in terms of adherence to it. Neither the CRTC or the NICC documents do that. The jurisdictions are different but the technical challenges are common. They can be summed up as call-routing and dispatch location delivery. For example, the NICC document does not specify i2; NICC just used i2 as a starting point since it deals with the same set of technical challenges. Beyond that it only references individuals specs (like HELD) as part of their own national specification. Again - I think this is a very valuable step for jurisdictions to take. It addresses the short term concerns that some operators may have about actual or self-imposed obligations. At the same time it lays down the fundamental LIS infrastructure that will ultimately allow VoIP-provider independent emergency calling to happen in an ECRIT-compliant manner. That next step is about as minimal in cost as it could be.

As another touch stone - all that was required for POTS emergency calling was PSTN access (some jurisdictions, e.g. USA, even dedicated trunks to the emergency service fromt the very edge of the network). All that should be needed to make emergency calls in the 21st century is a connection to the Internet.

Have a great weekend.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Fri 8/7/2009 10:12 PM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP
 
Hi Martin, 

Kind Regards

Laura

	Cheers,

	Martin

	You said:

	regards

	Keith

		Cheers,

		Martin

		Hi Martin, 

		 

		Laura

			Hi Roland,

			

			*	Allow AN operated LOST 

			[[LLi]]  

			Other comments below.

			Cheers,

			Martin

			 

			Dear all, 

			Just a few examples: 

			

			Best regards 

			Roland

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 7 Aug 2009 15:45:13 +0300

Ray, 
 
Laura wants to use the reverse DNS lookup by the proxy rather than the end
host. 
draft-thomson-geopriv-res-gw-lis-discovery talks about the end host usage
instead. 
 
Ciao
Hannes

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: 07 August, 2009 15:18
	To: [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [Ecrit] HUM on PhoneBCP

	Laura, 

	The main LIS Discovery draft from Geopriv previously did almost
exactly what you've just described, but it was changed because of complaints
from the DNS folk (myself included) that it assumed a mapping between domain
names and network access that simply often doesn't exist. 

	kind regards, 
	
	Ray

---

From: [email-masked]
Date: Fri, 7 Aug 2009 13:46:39 +0100

> draft-thomson-geopriv-res-gw-lis-discovery talks about the end host 
usage

Yes, it primarily talks about queries by the end-host, but also mentions 
that the exact same mechanism is also perfect for 3rd party LIS discovery 
requests.

See §3.2 and §4.3, although possibly this text about third party (proxy) 
queries could do with some beefing up.

Ray

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 7 Aug 2009 15:52:29 +0300

Thanks for pointing me to these sections. I will have a look at it. 

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: 07 August, 2009 15:47
To: Hannes Tschofenig
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Aug 2009 09:04:46 -0400

Actually, the PIDF-LO is designed to cater for all the variations in
addressing.  You don’t mean “location used for emergency calls”, you mean
“key for location used for emergency calls”.  The area code is not the
location, it is a key that is mapped to PSAP URI.  The telephone number
(with its area code) is the identifier you would use with HELD to get the
location, from which LoST would get you a PSAP URI.

This seems trivial for you to implement: you deploy a HELD server that takes
telephone number and returns a polygon representing the area code boundary,
and you deploy a LoST server that takes that polygon and returns the PSAP
URI associated with it.    This would be no more expensive than what you are
proposing.  Proxies could use this or phonebcp compatible endpoints could
use it.  

NENA is planning on doing pretty much this same thing to handle legacy
wireline networks where telephone number is currently the key to the
location database (ALI).  The LIS will store location as the key (using
held-identity), and a gateway will construct an LbyR from the phone number.
All the rest of the ecrit compatible infrastructure can then use the
Location URI to get location, route, etc.

Making what you now see as a one step mapping (area code to PSAP URI) into a
two step (telephone number to polygon, polygon to PSAP URI) is a bit more
complex, but not any significant difference in deployment.  It also works
for wireless (cell sector/ID to polygon, polygon to PSAP URI), and of
course, would be upwardly compatible with real location based routing,
should your systems evolve as we expect they evolve, or something like EU
regulations compel more accurate location services.

Brian

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, August 07, 2009 7:59 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] HUM on PhoneBCP

Hi Martin,  

Hi Laura,

[[LLi]] This is fine and usefull. Just that every country uses today
different formats for the location used for emergency calls. Changing this
will take time and costs money. 

What is the harm in allowing ECs to work with local location formats which
are understood only by the LIS and the PSAP ?. I dont see why a common
location format must be implemented by everybody. 

*	The proxy discovers the LIS based on EDs IP-address using
reverse-DNS and SRV record (this is possible with "identity extenssions")

*	It retrieves the location ( e.g. using HELD) in a local format
understood only by the LIS and the PSAP, which are in the same country. The
location is just a string which is passed transparently through the network
to the PSAP. In my opinion, it would be in principle  posible to use LbyR to
transport local location identidfiers, e. g.  [email-masked] , but
this is currently my personal opinion, I didn' found any statemant or
example in the drafts.   
*	The LIS delivers, together with the LbyR above, the PSAP URI.  As
far as I know there is currently no way to do this in HELD (or did I miss
something?).        

It would be an alternative which is interoperable and quite easy to
implement, without the need for the operators to change their location
databases. I think by allowing this scenario, interoperable EC could be
achieved earlier. And this does not exclude the scenario described in the
framework and phone-bcp, where the EDs retrieve deo or civic location, which
is needed for EC to work in private/enterprise networks.  

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. 
[[LLi]]  This is not quite true. We have to ensure that EC works for
different AN- and VoIP-provider and for nomadic users in Germany by 2013.
Our current solution does not allow this and there is the same for other
carriers. We definitively need to define in Germany an architecture which
fullfills this requirements. It would be very usefull if we can use standard
protocols. But nobody will be willing to change everything at once.  Having
a standard based architecture which is low cost would be a great advantage. 

Kind regards

Laura     

 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

  _____  

Hi Martin, 

 

Laura

Hi Roland,

*	Allow AN operated LOST 

[[LLi]]  

Other comments below.

Cheers,

Martin

  _____  

 

Dear all, 

Just a few examples: 

 

 

Best regards 

Roland

---

From: Marc Linsner <[email-masked]>
Date: Fri, 07 Aug 2009 09:26:04 -0400

> - and, VSPs can not do and will never do sip-location-conveyance.

This smells like regulators being manipulated by special interest to protect
business models.  Not surprising though, some business models can only
survive by stifling competition via regulation.  The only hope is that the
Internet is mature enough in the marketplace that the consumer will be able
to tell the difference and make the final decision.

-Marc-

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 15:33:52 +0200

This is correct. 
Thank you, Hannes. 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, August 07, 2009 2:45 PM
To: [email-masked]; Liess, Laura
Cc: [email-masked]; Jesske, Roland; [email-masked];

Ray, 
 
Laura wants to use the reverse DNS lookup by the proxy rather than the
end
host. 
draft-thomson-geopriv-res-gw-lis-discovery talks about the end host
usage
instead. 
 
Ciao
Hannes

	Cc: [email-masked]; [email-masked];
[email-masked];

	Laura, 

	The main LIS Discovery draft from Geopriv previously did almost
exactly what you've just described, but it was changed because of
complaints
from the DNS folk (myself included) that it assumed a mapping between
domain
names and network access that simply often doesn't exist. 
	
	The current proposal instead simply stores the LIS Discovery
U-NAPTR
records directly in the reverse DNS tree, where there's a much stronger
(almost 100%) mapping between the DNS and the network access provider. 
	
	kind regards, 
	
	Ray

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 16:44:39 +0200

Hi Brian,
 
Please see comments inline.  

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Friday, August 07, 2009 3:05 PM
	To: Liess, Laura; [email-masked]; Jesske, Roland; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Ecrit] HUM on PhoneBCP

	Actually, the PIDF-LO is designed to cater for all the variations in addressing.  You don't mean "location used for emergency calls", you mean "key for location used for emergency calls".  The area code is not the location, it is a key that is mapped to PSAP URI. 
	[[LLi]]  This is correct.

	  The telephone number (with its area code) is the identifier you would use with HELD to get the location,  from which LoST would get you a PSAP URI.
	[[LLi]] Here we don't use the phone number. The proxy sends the IP-address to the LIS. The LIS finds out the access hardware (DSLAM port)  corresponding to the IP-address and assigns a temporary string to it (kind of LbyR). It also finds out the phone area code for this hardware. With the phone area code, the LIS queries a table which contains the phone area codes and the corresponding PSAP URI,  then delivers the the string (LbyR) and the PSAP-URI to the SIP proxy. The SIP proxy routes the call and sends the LbyR to the PSAP. In very few cases, PSAPs dereference  the the LyBR to a civic address. 

	We do not have any kind of geo data or poligons in our database. In principle we have the the civic address, but the access to this data is quite slow.  I think other fixed networks carriers here have more or less the same. 

	This seems trivial for you to implement: you deploy a HELD server that takes telephone number and returns a polygon representing the area code boundary, and you deploy a LoST server that takes that polygon and returns the PSAP URI associated with it.   

	  This would be no more expensive than what you are proposing.  Proxies could use this or phonebcp compatible endpoints could use it.  

	NENA is planning on doing pretty much this same thing to handle legacy wireline networks where telephone number is currently the key to the location database (ALI).  The LIS will store location as the key (using held-identity), and a gateway will construct an LbyR from the phone number.  All the rest of the ecrit compatible infrastructure can then use the Location URI to get location, route, etc.

	Making what you now see as a one step mapping (area code to PSAP URI) into a two step (telephone number to polygon, polygon to PSAP URI) is a bit more complex, but not any significant difference in deployment.  It also works for wireless (cell sector/ID to polygon, polygon to PSAP URI), and of course, would be upwardly compatible with real location based routing, should your systems evolve as we expect they evolve, or something like EU regulations compel more accurate location services.

	[[LLi]] Nobody here is willing to putting geodata or poligons into the access databases.  And we could avoid doing this just by allowing the LIS to query the local LOST with the LbyR and to deliver the PSAP URI to the SIP proxy.  

	Kind regards

	Laura

	Brian

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

	Hi Martin,  

	Hi Laura,

		    

		Kind regards

		Laura     

		Cheers,

		Martin

		Hi Martin, 

		 

		Laura

			Hi Roland,

			

			*	Allow AN operated LOST 

			[[LLi]]  

			Other comments below.

			Cheers,

			Martin

			 

			Dear all, 

			Just a few examples: 

			

			Best regards 

			Roland

---

From: John Lange <[email-masked]>
Date: Fri, 07 Aug 2009 09:53:55 -0500

> ubiquitous emergency services via all devices/access... I would have

Ci2 has no allowance for SIP-location conveyance, period. You can deploy
location aware devices all you want but they will just be treated as
"dumb" voip endpoints in Ci2. There is nothing that allows devices to
discover their own location and even if they did (say through local
DHCP), that information it will be ignored.

That is why I say "devices are not location aware and never will be";
because Ci2 has no method for them to find their location _and_ even if
they have location it will be ignored.

Also, "VSPs can not do and will never do sip-location-conveyance";
because, Ci2 does not have sip-location-conveyance. If a VSP were to
send location to the ESGW, it would be ignored.

So the use of "never" is accurate. Some future version of Ci2 (Ci2.5 ?)
might allow these things but that is extremely unlikely given that the
entire location discovery mechanism is on an ILEC private network.

Under the proposed Ci2, the VSP has only one single ESGW. All the VSP
does is hand the emergency call to the ILEC's ESGW and the ILEC does all
the location discovery and call routing on a private network.

People naturally confuse NENAi2 with Ci2 but they have almost nothing in
common. Some ideas and terminology were borrowed from NENAi2 but it is
otherwise a completely different animal.

Fundamentally the difference is, NENAi2 "happens" on the internet. Ci2
"happens" on a private network accessible only to the ILEC(s). Ci2 will
never evolve into ECRIT because the network architecture prevents it.

-- 
John Lange
http://www.johnlange.ca

---

From: Marc Linsner <[email-masked]>
Date: Fri, 07 Aug 2009 11:32:25 -0400

Hmm, the PSTN will be an awful expense venture when the only thing on it are
PSAPs.

In the US, PSAPs have shown an interest to keep up with the advances in
their customer's modes of communication and take advantage of features
afforded by the new technologies.

So far, special interest hasn't been able to sway regulators into thinking
this is a bad idea.  Which is a good thing, IMO.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 7 Aug 2009 10:40:00 -0500

ECRIT still works if everything - the LIS, LoST, and the route to the PSAP occur in the access network and via a VPN or direct physical IP trunk to the PSAP. The ESGW is a PSAP URI.

So - assuming ILECS (and ISPs and broadband wireless providers and municipal WiFi networks...) who are putting in the location-determination infrastructure for Ci2 take the minimal step of allowing end device access to that location service, then the step to ECRIT can be made.

I'm saying that the investment in dynamic location determination capabilities in the network is the most significant step an operator needs to make toward ECRIT capability. So any architecture that does this does represent a significant step toward ECRIT... whether that's the intention or not.

> entire location discovery mechanism is on an ILEC private network.

I think that pretty much establishes that the extent of our disagreement is only a matter of degree. Never doesn't have to mean never; it boils down to what one thinks most likely. I'm happy to say that I think that Canada will support a more comprehensive access to emergency calling than Ci2 offers at the outset.

On a side-note, there's a common view that emergency calling is all about VoIP services - and I think this view only arises because people tend to "talk" to PSAPs. The service that LECs provided subscribers in POTS days was the ability to establish a circuit from their point of subscription to any other address (aka phone number) on the global PSTN. The most common use people made of that circuit was to talk to each other... but voice is just an application of the service and not the service itself; the circuits also got used for sending fax, monitoring security systems, and even point to point IP data. That is, LECs don't have some sort of natural right or ownership of the voice application.

Now we're in ISP times; the fundamental service the "LECs" provide their subscribers is the ability to send an IP packet to any other point (aka IP address) on the global Internet. In POTS days, calling emergency services got the subscriber a circuit to the PSAP. In Internet times, calling emergency services means getting an IP packet session  established with the PSAP (SIP with the option of audio or text media as a starting point having emerged as the dominant assumption). Letting the users of the end devices do this should not be predicated on them having to have a VoIP service on that network, in that country, or at all for that matter. As with voice in a PSTN context, VoIP is an application (just an Internet presence service actually). I liken the insistence on the use of a VoIP provider to make emergency calls in the Internet era to insisting on the use of long distance providers to make emergency calls in the POTS era.

Cheers,
Martin 

-----Original Message-----
From: John Lange [mailto:[email-masked]]
Sent: Sat 8/8/2009 12:53 AM
To: Dawson, Martin
Cc: ecrit
Subject: RE: [Ecrit] HUM on PhoneBCP

-- 
John Lange
http://www.johnlange.ca

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Aug 2009 11:45:31 -0400

Laura

I don’t think we’re going to get to the point where the IETF rolls back
–framework and –phonebcp far enough to suit you.  The approach that Hannes
described, which is to finish the current work as is, and then go back and
see if we can standardize a way for VoIP services to connect to older
systems with more limited capabilities using OBO and other tricks, makes
some sense to me.  

However, device vendors have to build devices that work in countries that
are more aggressively upgrading their emergency systems, without unduly
burdening you.  What I’m attempting to do is to figure out a way that you
can work with a –phonebcp compliant device, without incurring a lot of cost.

We’re not going to make it zero.

If you don’t like a poly, return any street address in the area code.  In
most cases, it could be a PIDF with a couple of A levels that works for the
town.

All that matters is that if a –phonebcp client queries an LCP, it should get
a location that, when passed to LoST, gets the right URI.  If the location
is coarse, that is okay; it works.  I’d like you to deploy HELD and LoST
servers in your networks that return the right thing to the endpoint and not
just to the OBO proxy, but even if you don’t, phonebcp compliant end devices
will “work” in your network: their attempts to reach LIS and LoST servers
will fail, and they will send emergency calls without location and PSAP URI,
and your proxy can fill in the right stuff.

You don’t need –phonebcp compliant endpoints.  Good for you.  However,
vendors ought to make phonebcp compliant endpoints so that they work
everywhere.

If you want less that that, then I’m not sure IETF can oblige, since we
don’t do nation specific solutions and some nations need the full –phonebcp
spec.

One complication you should consider: devices need to know the local dial
string(s) for emergency calls.  In the IETF architecture, LoST provides
that.  What were you planning on doing?

Brian

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 07, 2009 10:45 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP

Hi Brian,

 

  _____  

Actually, the PIDF-LO is designed to cater for all the variations in
addressing.  You don’t mean “location used for emergency calls”, you mean
“key for location used for emergency calls”.  The area code is not the
location, it is a key that is mapped to PSAP URI. 
[[LLi]]  This is correct.

  The telephone number (with its area code) is the identifier you would use
with HELD to get the location,  from which LoST would get you a PSAP URI.
[[LLi]] Here we don't use the phone number. The proxy sends the IP-address
to the LIS. The LIS finds out the access hardware (DSLAM port)
corresponding to the IP-address and assigns a temporary string to it (kind
of LbyR). It also finds out the phone area code for this hardware. With the
phone area code, the LIS queries a table which contains the phone area codes
and the corresponding PSAP URI,  then delivers the the string (LbyR) and the
PSAP-URI to the SIP proxy. The SIP proxy routes the call and sends the LbyR
to the PSAP. In very few cases, PSAPs dereference  the the LyBR to a civic
address. 

We do not have any kind of geo data or poligons in our database. In
principle we have the the civic address, but the access to this data is
quite slow.  I think other fixed networks carriers here have more or less
the same. 

URI associated with it.   

  This would be no more expensive than what you are proposing.  Proxies
could use this or phonebcp compatible endpoints could use it.  

[[LLi]] Nobody here is willing to putting geodata or poligons into the
access databases.  And we could avoid doing this just by allowing the LIS to
query the local LOST with the LbyR and to deliver the PSAP URI to the SIP
proxy.  

Kind regards

Laura

Brian

 

Hi Martin,  

Hi Laura,

·         The proxy discovers the LIS based on EDs IP-address using
reverse-DNS and SRV record (this is possible with "identity extenssions") 

·         It retrieves the location ( e.g. using HELD) in a local format

·         The LIS delivers, together with the LbyR above, the PSAP URI.  As
far as I know there is currently no way to do this in HELD (or did I miss
something?).        

    

Kind regards

Laura     

Cheers,

Martin

  _____  

Hi Martin, 

 

Laura

Hi Roland,

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

[[LLi]]  

Other comments below.

Cheers,

Martin

  _____  

 

Dear all, 

Just a few examples: 

 

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

o    The MUST for the end devices to support location information, DHCP
location options and HELD shall be removed 

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

Best regards 

Roland

---

From: John Lange <[email-masked]>
Date: Fri, 07 Aug 2009 14:59:45 -0500

On Fri, 2009-08-07 at 10:40 -0500, Dawson, Martin wrote:
> I'm saying that the investment in dynamic location determination
> capabilities in the network is the most significant step an operator
> needs to make toward ECRIT capability. So any architecture that does
> this does represent a significant step toward ECRIT... whether that's
> the intention or not.

Certainly location determination is what it's all about and I grant you
that having that capability in any form is a potential step forward.

But I emphasis that the way it's implemented will have a large impact on
future uses. A private network/proprietary implementation likely does
not get you any closer to ECRIT compliance.

Consider that, once implemented, the Ci2 infrastructure would have to be
left in place to support users and devices that have come to rely on it.
The private networks, the proprietary protocols, everything would have
to stay indefinitely just as existing PSAP wireline will be around for
the long hall.

Though we may discuss bringing Ci2 into compliance with ECRIT as being
an "upgrade", what we are really talking about is yet another complete
infrastructure build while still keeping the legacy systems operating.

If we are lucky there may be some components that can function on both
networks but that seems unlikely given that given that the methodology
and protocols described in Ci2 are not compatible with either current
ECRIT work or even legacy NENAi2.

Furthermore, once the system is deployed, who will be motivated to
evolve to ECRIT compliance?

The public? No. the Ci2 system works = nobody dies = no public outcry =
no upgrade.

The ILECs? No. Their competitors (the VOIP providers) are now tied into
them as the monopoly supplier of emergency services. A perfect way to
keep them less competitive.

The regulator? No. See "The public" above.

The PSAPs? No. See "The public" above.

The VSPs? Yes! But who cares? See "the regulator" above.

> I think that pretty much establishes that the extent of our
> disagreement is only a matter of degree.

Agreed. We are only arguing semantics at this point.

I feel strongly that if Ci2 is implemented the way it is currently
proposed it will be very bad for VOIP providers and by extension the
Canadian public.

-- 
John Lange
http://www.johnlange.ca

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 8 Aug 2009 02:56:43 -0500

OK... I don't really have a view on whether Ci2 is the *best* first step
or not.

Presumably the first "casualty" would be somebody from an
ECRIT-compliant jurisdiction who expected they could make a reliable
emergency call on the WiFi hotspot they're visiting using the standard
emergency client on their WiFi device.

Cheers,
Martin

-----Original Message-----
From: John Lange [mailto:[email-masked]] 
Sent: Saturday, 8 August 2009 6:00 AM
To: Dawson, Martin
Cc: ecrit
Subject: RE: [Ecrit] HUM on PhoneBCP

-- 
John Lange
http://www.johnlange.ca

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 8 Aug 2009 15:02:23 +0300

Hi John, 

in addition to what Martin said about the negative impact on the "public". 

My guess is that the emergency services networks will move their networks to
IP (because of the lower costs) and then they will not require the ILECs
todo the gatewaying of all the calls. They will be able to get emergency
calls directly from the VoIP providers. This will be less expensive, will
support additional media and more extensible for future deployments. This is
an evolution step we observe in many countries.  

One interesting data point I would like to understand is whether the
PSAPs/emergency services networks have to pay to the ILECs for their
emergency call routing and gatewaying "offering". If they have to then there
is obviously incentive for them to move away from that model. 

Regarding the VSPs vs. the ILECs: It depends on the regulator to balance the
responsibilities between the two. This is largely a discussion that relates
to net neutrality (there was a nice plenary discussion about that topic at
the last IETF meeting). 

Ciao
Hannes

PS: I am always curious why people see the step to a NENA i2.5 or pre-ECRIT
architecture as so complicated particularly when the largest investment is
in the location server capability in the access networks (and those have to
be done anyway regardless of the chosen architecture).  

>Sent: 08 August, 2009 10:57
>To: John Lange
>Cc: ecrit
>OK... I don't really have a view on whether Ci2 is the *best* 
>first step or not.
>
>ECRIT-compliant jurisdiction who expected they could make a 
>reliable emergency call on the WiFi hotspot they're visiting 
>using the standard emergency client on their WiFi device.
>
>Cheers,
>Martin
>
>Certainly location determination is what it's all about and I 
>grant you that having that capability in any form is a 
>potential step forward.
>
>But I emphasis that the way it's implemented will have a large 
>impact on future uses. A private network/proprietary 
>implementation likely does not get you any closer to ECRIT compliance.
>
>Consider that, once implemented, the Ci2 infrastructure would 
>have to be left in place to support users and devices that 
>have come to rely on it.
>The private networks, the proprietary protocols, everything 
>would have to stay indefinitely just as existing PSAP wireline 
>will be around for the long hall.
>
>Though we may discuss bringing Ci2 into compliance with ECRIT 
>as being an "upgrade", what we are really talking about is yet 
>another complete infrastructure build while still keeping the 
>legacy systems operating.
>
>If we are lucky there may be some components that can function 
>on both networks but that seems unlikely given that given that 
>the methodology and protocols described in Ci2 are not 
>compatible with either current ECRIT work or even legacy NENAi2.
>
>Furthermore, once the system is deployed, who will be 
>motivated to evolve to ECRIT compliance?
>
>The public? No. the Ci2 system works = nobody dies = no public 
>outcry = no upgrade.
>
>The ILECs? No. Their competitors (the VOIP providers) are now 
>tied into them as the monopoly supplier of emergency services. 
>A perfect way to keep them less competitive.
>
>I feel strongly that if Ci2 is implemented the way it is 
>currently proposed it will be very bad for VOIP providers and 
>by extension the Canadian public.
>
>--
>John Lange
>http://www.johnlange.ca
>
>

---

From: <[email-masked]>
Date: Mon, 10 Aug 2009 15:57:49 +0200

Brian,
 
My expectation was that framework and phonepcb contain enough options to cover also short term scenarios and help us to implement VoIP emergency calling now. This seems not to be the case. We can not require now from our SIP-proxy vendors to comply with the framework and phone-pcb because this does not work with the existing EDs.  Currently, ECRIT does not offer all components to build an EC architecture which works now. As a result, DT and other carriers must build and require from their vendors proprietary solutions which work now.
 
We can take the approach that Hannes describes and do it later, it's better than not at all. However, when people already have proprietary solutions in place, it is difficult change them.
 
Concerning the local dial string, we do not have currently any plans for something different from 112 and the national EC dial string (110) or to allow the nomadic usage of the VoIP service outside Germany. 
 
Laura

	Sent: Friday, August 07, 2009 5:46 PM

	Laura

	I don't think we're going to get to the point where the IETF rolls back -framework and -phonebcp far enough to suit you.  The approach that Hannes described, which is to finish the current work as is, and then go back and see if we can standardize a way for VoIP services to connect to older systems with more limited capabilities using OBO and other tricks, makes some sense to me.  

	However, device vendors have to build devices that work in countries that are more aggressively upgrading their emergency systems, without unduly burdening you.  What I'm attempting to do is to figure out a way that you can work with a -phonebcp compliant device, without incurring a lot of cost.

	We're not going to make it zero.

	If you don't like a poly, return any street address in the area code.  In most cases, it could be a PIDF with a couple of A levels that works for the town.

	All that matters is that if a -phonebcp client queries an LCP, it should get a location that, when passed to LoST, gets the right URI.  If the location is coarse, that is okay; it works.  I'd like you to deploy HELD and LoST servers in your networks that return the right thing to the endpoint and not just to the OBO proxy, but even if you don't, phonebcp compliant end devices will "work" in your network: their attempts to reach LIS and LoST servers will fail, and they will send emergency calls without location and PSAP URI, and your proxy can fill in the right stuff.

	You don't need -phonebcp compliant endpoints.  Good for you.  However, vendors ought to make phonebcp compliant endpoints so that they work everywhere.

	If you want less that that, then I'm not sure IETF can oblige, since we don't do nation specific solutions and some nations need the full -phonebcp spec.

	One complication you should consider: devices need to know the local dial string(s) for emergency calls.  In the IETF architecture, LoST provides that.  What were you planning on doing?

	Brian

	To: [email-masked]; [email-masked]; [email-masked]; [email-masked]

	Hi Brian,

		 

		Kind regards

		Laura

		Brian

		 

		Hi Martin,  

		Hi Laura,

			·         The proxy discovers the LIS based on EDs IP-address using reverse-DNS and SRV record (this is possible with "identity extenssions") 

			·         It retrieves the location ( e.g. using HELD) in a local format understood only by the LIS and the PSAP, which are in the same country. The location is just a string which is passed transparently through the network to the PSAP. In my opinion, it would be in principle  posible to use LbyR to transport local location identidfiers, e. g.  [email-masked] , but this is currently my personal opinion, I didn' found any statemant or example in the drafts.    

			·         The LIS delivers, together with the LbyR above, the PSAP URI.  As far as I know there is currently no way to do this in HELD (or did I miss something?).        

			    

			Kind regards

			Laura     

			Cheers,

			Martin

			Hi Martin, 

			 

			Laura

				Hi Roland,

				

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

				[[LLi]]  

				Other comments below.

				Cheers,

				Martin

				 

				Dear all, 

				Just a few examples: 

				

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

				o    The MUST for the end devices to support location information, DHCP location options and HELD shall be removed 

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

				Best regards 

				Roland

---

From: John Lange <[email-masked]>
Date: Mon, 10 Aug 2009 16:15:28 -0500

I'm changing the topic on this thread to accurately reflect the fact  
that were straying off topic for this mailing list ;)

Quoting Hannes Tschofenig <[email-masked]>:

> todo the gatewaying of all the calls.

That will not happen any time soon. The PSAPs have sworn allegiance to  
the ILECs and will not connect their equipment to anything except the  
ILECs. They have reiterated this frequently.

> They will be able to get emergency calls directly from the VoIP providers.

As long as the current PSAP management is involved that will never  
happen. They have stated this time and again. No PSAP system will ever  
be connected to the Internet.

> This will be less expensive, will
> emergency call routing and gatewaying "offering".

Yes the ILECs get compensation for their services though I do not know  
the exact model and I suspect it's different in province.

On top of that the various providers are allowed to charge a "911  
access fee" to every subscriber including wireless and standard  
wireline. This is a major source of revenue which they are motivated  
to protect.

They recently took some heat about this when it was revealed that this  
charge has nothing whatever to do with the actual cost of providing  
the service and they are under no obligation to spend the money to  
improve 911 service.

Case in point, we still can't do location for cell phones despite the  
fact that the one time cost of implementing the system would only be a  
fraction of the money collected in 911 fees EACH YEAR.

> If they have to then there is obviously incentive for them to move  
> away from that model.

I wouldn't say it's obvious. In fact I don't think saving the public  
money is anywhere near the top of PSAP motivations. For example,  
Ontario has something like 140(!) regional PSAPs (pretty much every  
municipality has one but I can't seem to get a straight answer on  
exactly how many there are). Roughly one PSAP for every 80,000 people.  
One of the big stumbling blocks to this whole process is that PSAPs  
will have to upgrade equipment. That gets expensive when you have to  
do it 140 times.

No PSAP is going to suggest "hey, this would be a good time  
consolidate 140 PSAPs and save a bundle of money!"

Rather, PSAPs are motivated by bad press. They avoid anything that may  
cause them not to be able to do their jobs and that boils down to  
"change".

I agree with them that we should be conservative with regard to change  
in the 911 system but the problem is the Canadian PSAPs have become a  
too dogmatic fighting change.

They actually tried to convince the CRTC to ban VOIP outright and  
since then they've spent too much of their time fighting change rather  
than considering what benefits new 911 systems could offer.

> be done anyway regardless of the chosen architecture).

Conversely, I find those kinds of statements as highly curious. From a  
technical perspective, real-time IP location is complicated. But never  
mind the technical, it's the politics that are the real challenge.

Consider that all IP location proposals rely on the ASP to implement a  
significant portion of the solution and that almost all ASPs (in  
Canada) also provide phone service.

Not only does spending money on IP location do nothing to enhance  
their internet offerings, it actually enhances the VOIP service  
offering of their competition. (yes I know you could technically argue  
that location enhances their service but that will never result in  
more customers, especially given that all ASPs would be required to  
have the same thing)

And that is only one example.

Pretty much everyone agrees that a LIS is the first step in any system  
but that's a long way from having a cost effective working IP location  
system.

-- 
John Lange

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Aug 2009 21:57:09 -0400

Your PSAPs are a year or two behind ours.  Ours said the same thing when we
first started talking about i3.  Just about all of them are now eager to get
upgraded, although they aren't sure how they will pay for upgrades yet (or
what it will cost).

Fear, uncertainty, and doubt pervade this environment.  Education changes
the perceptions.

Brian

> Sent: Monday, August 10, 2009 5:15 PM
> To: Hannes Tschofenig
> Cc: 'Dawson, Martin'; 'ecrit'
> Subject: [Ecrit] PSAP motivations
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 08:56:27 +0100

> Sent: 10 August 2009 14:58
> My expectation was that framework and phonepcb contain enough 
> options to cover also short term scenarios and help us to 
> implement VoIP emergency calling now. This seems not to be 
> the case. We can not require now from our SIP-proxy vendors 
> to comply with the framework and phone-pcb because this does 
> not work with the existing EDs.  Currently, ECRIT does not 
> offer all components to build an EC architecture which works 
> now. As a result, DT and other carriers must build and 
> require from their vendors proprietary solutions which work now.
>  
> We can take the approach that Hannes describes and do it 
> later, it's better than not at all. However, when people 
> already have proprietary solutions in place, it is difficult 
> change them.
>  
> Concerning the local dial string, we do not have currently 
> any plans for something different from 112 and the national 
> EC dial string (110) or to allow the nomadic usage of the 
> VoIP service outside Germany. 
[JRE] But how does a visiting device from the US, say, discover that the local dial string in Germany is 112?

John

> 	I don't think we're going to get to the point where the 
> IETF rolls back -framework and -phonebcp far enough to suit 
> you.  The approach that Hannes described, which is to finish 
> the current work as is, and then go back and see if we can 
> standardize a way for VoIP services to connect to older 
> systems with more limited capabilities using OBO and other 
> tricks, makes some sense to me.  
> 
> 	 
> 
> 	However, device vendors have to build devices that work 
> in countries that are more aggressively upgrading their 
> emergency systems, without unduly burdening you.  What I'm 
> attempting to do is to figure out a way that you can work 
> with a -phonebcp compliant device, without incurring a lot of cost.
> 
> 	 
> 
> 	If you don't like a poly, return any street address in 
> the area code.  In most cases, it could be a PIDF with a 
> couple of A levels that works for the town.
> 
> 	 
> 
> 	All that matters is that if a -phonebcp client queries 
> an LCP, it should get a location that, when passed to LoST, 
> gets the right URI.  If the location is coarse, that is okay; 
> it works.  I'd like you to deploy HELD and LoST servers in 
> your networks that return the right thing to the endpoint and 
> not just to the OBO proxy, but even if you don't, phonebcp 
> compliant end devices will "work" in your network: their 
> attempts to reach LIS and LoST servers will fail, and they 
> will send emergency calls without location and PSAP URI, and 
> your proxy can fill in the right stuff.
> 
> 	 
> 
> 	You don't need -phonebcp compliant endpoints.  Good for 
> you.  However, vendors ought to make phonebcp compliant 
> endpoints so that they work everywhere.
> 
> 	 
> 
> 	If you want less that that, then I'm not sure IETF can 
> oblige, since we don't do nation specific solutions and some 
> nations need the full -phonebcp spec.
> 
> 	 
> 
> 	One complication you should consider: devices need to 
> know the local dial string(s) for emergency calls.  In the 
> IETF architecture, LoST provides that.  What were you 
> planning on doing?
> 
> 	 
> 
> 	Brian
> 
> 	 
> 
> 	 
> 
> 		Actually, the PIDF-LO is designed to cater for 
> all the variations in addressing.  You don't mean "location 
> used for emergency calls", you mean "key for location used 
> for emergency calls".  The area code is not the location, it 
> is a key that is mapped to PSAP URI. 
> 		[[LLi]]  This is correct.
> 
> 		 
> 
> 		  The telephone number (with its area code) is 
> the identifier you would use with HELD to get the location,  
> from which LoST would get you a PSAP URI.
> 		[[LLi]] Here we don't use the phone number. The 
> proxy sends the IP-address to the LIS. The LIS finds out the 
> access hardware (DSLAM port)  corresponding to the IP-address 
> and assigns a temporary string to it (kind of LbyR). It also 
> finds out the phone area code for this hardware. With the 
> phone area code, the LIS queries a table which contains the 
> phone area codes and the corresponding PSAP URI,  then 
> delivers the the string (LbyR) and the PSAP-URI to the SIP 
> proxy. The SIP proxy routes the call and sends the LbyR to 
> the PSAP. In very few cases, PSAPs dereference  the the LyBR 
> to a civic address. 
> 
> 		We do not have any kind of geo data or poligons 
> in our database. In principle we have the the civic address, 
> but the access to this data is quite slow.  I think other 
> fixed networks carriers here have more or less the same. 
> 
> 		 
> 
> 		This seems trivial for you to implement: you 
> deploy a HELD server that takes telephone number and returns 
> a polygon representing the area code boundary, and you deploy 
> a LoST server that takes that polygon and returns the PSAP 
> URI associated with it.   
> 
> 		  This would be no more expensive than what you 
> are proposing.  Proxies could use this or phonebcp compatible 
> endpoints could use it.  
> 
> 		 
> 
> 		NENA is planning on doing pretty much this same 
> thing to handle legacy wireline networks where telephone 
> number is currently the key to the location database (ALI).  
> The LIS will store location as the key (using held-identity), 
> and a gateway will construct an LbyR from the phone number.  
> All the rest of the ecrit compatible infrastructure can then 
> use the Location URI to get location, route, etc.
> 
> 		 
> 
> 		Making what you now see as a one step mapping 
> (area code to PSAP URI) into a two step (telephone number to 
> polygon, polygon to PSAP URI) is a bit more complex, but not 
> any significant difference in deployment.  It also works for 
> wireless (cell sector/ID to polygon, polygon to PSAP URI), 
> and of course, would be upwardly compatible with real 
> location based routing, should your systems evolve as we 
> expect they evolve, or something like EU regulations compel 
> more accurate location services.
> 
> 		[[LLi]] Nobody here is willing to putting 
> geodata or poligons into the access databases.  And we could 
> avoid doing this just by allowing the LIS to query the local 
> LOST with the LbyR and to deliver the PSAP URI to the SIP proxy.  
> 
> 		 
> 
> 		Kind regards
> 
> 		Laura
> 
> 		 
> 
> 		Brian
> 
> 		 
> 
> 		From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 			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.
> 
> 			[[LLi]] This is fine and usefull. Just 
> that every country uses today different formats for the 
> location used for emergency calls. Changing this will take 
> time and costs money. 
> 
> 			What is the harm in allowing ECs to 
> work with local location formats which are understood only by 
> the LIS and the PSAP ?. I dont see why a common location 
> format must be implemented by everybody. 
> 
> 			·         The proxy discovers the LIS 
> based on EDs IP-address using reverse-DNS and SRV record 
> (this is possible with "identity extenssions") 
> 
> 			·         It retrieves the location ( 
> e.g. using HELD) in a local format understood only by the LIS 
> and the PSAP, which are in the same country. The location is 
> just a string which is passed transparently through the 
> network to the PSAP. In my opinion, it would be in principle  
> posible to use LbyR to transport local location identidfiers, 
> e. g.  [email-masked] , but this is currently my 
> personal opinion, I didn' found any statemant or example in 
> the drafts.    
> 
> 			·         The LIS delivers, together 
> with the LbyR above, the PSAP URI.  As far as I know there is 
> currently no way to do this in HELD (or did I miss 
> something?).        
> 			  
> 
> 			It would be an alternative which is 
> interoperable and quite easy to implement, without the need 
> for the operators to change their location databases. I think 
> by allowing this scenario, interoperable EC could be achieved 
> earlier. And this does not exclude the scenario described in 
> the framework and phone-bcp, where the EDs retrieve deo or 
> civic location, which is needed for EC to work in 
> private/enterprise networks.  
> 			  
> 
> 			    
> 
> 			 
> 
> 			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. 
> 			[[LLi]]  This is not quite true. We 
> have to ensure that EC works for different AN- and 
> VoIP-provider and for nomadic users in Germany by 2013. Our 
> current solution does not allow this and there is the same 
> for other carriers. We definitively need to define in Germany 
> an architecture which fullfills this requirements. It would 
> be very usefull if we can use standard protocols. But nobody 
> will be willing to change everything at once.  Having a 
> standard based architecture which is low cost would be a 
> great advantage. 
> 
> 			 
> 
> 			Kind regards
> 
> 			Laura     
> 
> 			 
> 
> 			 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dawson, Martin
> 				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.   
> 
> 				 
> 
> 				[[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 
> 				·         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 
> 				[[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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 				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. 
> 
> 				Back to the document: Some 
> requirements are far form being realistic, at least in 
> Germany, some are not realistic at all. Implementing these 
> 				·       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 
> 				[[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 
> 				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 
> 				o    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) 
> 
> 				o    The MUST for the end 
> devices to support location information, DHCP location 
> options and HELD shall be removed 
> 
> 				o    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 
> 
> 				 
> 
> <mailto:[email-masked]>  
> 				http://www.telekom.de 
> <http://www.telekom.de/>  
> 
> 				 
> 
> 				Geschäftsführung: Dr. Bruno 
> Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
> 				contain privileged, 
> proprietary, or otherwise private information.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 11 Aug 2009 11:03:26 +0300

>[JRE] But how does a visiting device from the US, say, 
>discover that the local dial string in Germany is 112?

RFC 5222: http://www.ietf.org/rfc/rfc5222.txt 

(It would also discover any other emergency number used in Germany)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 Aug 2009 09:04:58 +0100

I know that, but I thought Laura was arguing against the need to support
LoST. With the rest of the thread stripped, my question below appears
our of context.

John 

> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: 11 August 2009 09:03
> To: Elwell, John; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Tue, 11 Aug 2009 11:12:50 +0200

John, 

It depends on who operates the device. An IMS mobile operator will support this because the P-CSCF will be in Germany and will recognize 112 as an EC. For the fixed networks, we are not aware of any requirements to support non-IMS nomadic devices operated from the US. It is in principle a nice thing, but we do not have requirements for this.   

More than that, the new German law (March 2009) is more restrictive then the old one. EC from mobile phones without valid SIM-card are no longer allowed and carriers must ensure that they do not route calls originated outside Germany to german PSAPs.   This is because PSAPs have problems to distinguish between real and bogus ECs. The real problem is the PSAPs overload, they just do not have enough people to answer the calls they get. Other than in US and Canada, there is no "112 access fee" in Germany.       

Laura

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, August 11, 2009 9:56 AM
To: Liess, Laura; [email-masked]; [email-masked]; Jesske, Roland; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] HUM on PhoneBCP

John

---

From: Nate Wilcox <[email-masked]>
Date: Tue, 11 Aug 2009 09:07:51 -0400

Huh?

Major PSAP jurisdictions in the US are in the process of moving to IP
(Oklahoma City, OK (ACOG), San Antonio, Texas (Bexar Metro), North
West Chicago, IL (NWCDS)) and at least 2 ILEC's that I know of (Embarq
and AT&T) are actively engaged in moving their 9-1-1 systems to VoIP.
Direct connectivity to the Internet is a common piece of the overall
ESInet that these agencies/companies are deploying. In fact, last week
in San Antonio we delivered test 9-1-1 calls from clients on the
Internet directly to 9-1-1 call taking positions - we used PIDF-LO
capable clients and derived location information in a variety of
formats from a LIS.

Nate Wilcox

On Mon, Aug 10, 2009 at 5:15 PM, John Lange<[email-masked]> wrote:
> I'm changing the topic on this thread to accurately reflect the fact that
> were straying off topic for this mailing list ;)
>
> That will not happen any time soon. The PSAPs have sworn allegiance to the
> ILECs and will not connect their equipment to anything except the ILECs.
> They have reiterated this frequently.
>
> As long as the current PSAP management is involved that will never happen.
> They have stated this time and again. No PSAP system will ever be connected
> to the Internet.
>
> Yes the ILECs get compensation for their services though I do not know the
> exact model and I suspect it's different in province.
>
> On top of that the various providers are allowed to charge a "911 access
> fee" to every subscriber including wireless and standard wireline. This is a
> major source of revenue which they are motivated to protect.
>
> charge has nothing whatever to do with the actual cost of providing the
> service and they are under no obligation to spend the money to improve 911
> service.
>
> Case in point, we still can't do location for cell phones despite the fact
> that the one time cost of implementing the system would only be a fraction
> of the money collected in 911 fees EACH YEAR.
>
>> If they have to then there is obviously incentive for them to move away
>> from that model.
>
> I wouldn't say it's obvious. In fact I don't think saving the public money
> is anywhere near the top of PSAP motivations. For example, Ontario has
> something like 140(!) regional PSAPs (pretty much every municipality has one
> but I can't seem to get a straight answer on exactly how many there are).
> Roughly one PSAP for every 80,000 people. One of the big stumbling blocks to
> this whole process is that PSAPs will have to upgrade equipment. That gets
> expensive when you have to do it 140 times.
>
> No PSAP is going to suggest "hey, this would be a good time consolidate 140
> PSAPs and save a bundle of money!"
>
> Rather, PSAPs are motivated by bad press. They avoid anything that may cause
> them not to be able to do their jobs and that boils down to "change".
>
> I agree with them that we should be conservative with regard to change in
> the 911 system but the problem is the Canadian PSAPs have become a too
> dogmatic fighting change.
>
> They actually tried to convince the CRTC to ban VOIP outright and since then
> they've spent too much of their time fighting change rather than considering
> what benefits new 911 systems could offer.
>
> technical perspective, real-time IP location is complicated. But never mind
> the technical, it's the politics that are the real challenge.
>
> significant portion of the solution and that almost all ASPs (in Canada)
> also provide phone service.
>
> Not only does spending money on IP location do nothing to enhance their
> internet offerings, it actually enhances the VOIP service offering of their
> competition. (yes I know you could technically argue that location enhances
> their service but that will never result in more customers, especially given
> that all ASPs would be required to have the same thing)
>
> Pretty much everyone agrees that a LIS is the first step in any system but
> that's a long way from having a cost effective working IP location system.
>
> --
> John Lange
>
>

---

From: John Lange <[email-masked]>
Date: Tue, 11 Aug 2009 14:00:04 -0500

> Major PSAP jurisdictions in the US are in the process of moving to IP

Note that my comments are always with regard to Canadian PSAPs unless
stated otherwise.

I apologize for any confusion.
-- 
John Lange
http://www.johnlange.ca

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Aug 2009 13:03:08 -0400

> That is the absolute critical point!

To be precise, however, the scenario Brian is describing still leaves a 
gap: VoIP users that use a VoIP provider outside of the jurisdiction 
will not be able to make emergency calls.  For instance, if I took a 
Vonage ATA to Canada, and Vonage didn't have a pre-existing relationship 
with the ISP I was using, Vonage would be unable to route my calls.

What Brian is describing is a transition strategy.  As you point out, 
John, it's a critical one, and the path most jurisdictions are starting 
with.  But it's not the complete solution.

--Richard

---

From: John Lange <[email-masked]>
Date: Thu, 13 Aug 2009 14:44:56 -0500

On Wed, 2009-08-12 at 13:03 -0400, Richard Barnes wrote:
> will not be able to make emergency calls.

Actually, it might be better to say "may not be able to" or at least
"there would likely not be any regulatory requirement that the emergency
call be completed."

>   For instance, if I took a 

Most likely that would be true but if the jurisdictions implement the
same solutions then there is chance that companies that have a presence
in both areas would be able to support their customers that roam between
them. That is why I suggest it might be possible to complete calls.

> with.  But it's not the complete solution.

The best case scenario is for ECRIT to get the standards done that
comprise the interim solution before the various jurisdictions start
implementing them.

Hopefully we would all have something compatible if and when
phone-bcp/ecrit-framework ever becomes practical to implement.

-- 
John Lange
http://www.johnlange.ca