Re: [Ecrit] HUM on PhoneBCP

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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



________________________________

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

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

	 

	Cheers,

	Martin

	 

	
________________________________


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

	 

	Hi Martin, 

	 

	See comments inline [[LLi]].

	 

	 

	Laura

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

		Hi Roland,

		 

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

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

		 

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

		 

		 

		 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. 

		 

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

		 

		 

		 

		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  

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

		 

		[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 

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

		 

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

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

		 

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

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

		 

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

		 

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

		 

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

		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.

		 

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

		 

		 

		 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.

		 

		[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

		 

		
________________________________


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

		 

		 

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

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

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

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

		Just a few examples: 

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

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

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

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

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

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

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

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

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

		 Think about it; all the complexity of putting location determination infrastructure in place for the purposes of dispatch is done - and then the next, simpler step, of using that to support the routing procedure isn't taken... that would be a waste.
		
		[[LLi]]  Do you think this is an argument for a product manager? They need a business case.  

		 

		 

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

		We could agree with the document with following changes: 

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

		 

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

		Best regards 

		Roland 

		 

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

		 

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

		 

		 


------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

		 




------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]