Re: [Ecrit] HUM on PhoneBCP

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of [e-mail]
> Sent: 10 August 2009 14:58
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 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. 
[JRE] But how does a visiting device from the US, say, discover that the local dial string in Germany is 112?

John


>  
> Laura
>  
> 
> 
> ________________________________
> 
> 	From: Brian Rosen [mailto:[e-mail]] 
> 	Sent: Friday, August 07, 2009 5:46 PM
> 	To: Liess, Laura; [e-mail]; Jesske, 
> Roland; [e-mail]
> 	Cc: [e-mail]
> 	Subject: RE: [Ecrit] HUM on PhoneBCP
> 	
> 	
> 
> 	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: [e-mail] [mailto:[e-mail]] 
> 	Sent: Friday, August 07, 2009 10:45 AM
> 	To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> 	Cc: [e-mail]
> 	Subject: RE: [Ecrit] HUM on PhoneBCP
> 
> 	 
> 
> 	Hi Brian,
> 
> 	 
> 
> 	Please see comments inline.  
> 
> 	 
> 
> 		 
> 
> 		________________________________
> 
> 				From: Brian Rosen 
> [mailto:[e-mail]] 
> 		Sent: Friday, August 07, 2009 3:05 PM
> 		To: Liess, Laura; [e-mail]; 
> Jesske, Roland; [e-mail]
> 		Cc: [e-mail]
> 		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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> 		Sent: Friday, August 07, 2009 7:59 AM
> 		To: [e-mail]; 
> [e-mail]; [e-mail]
> 		Cc: [e-mail]
> 		Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 		 
> 
> 		 
> 
> 		Hi Martin,  
> 
> 		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.
> 
> 			[[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.  [e-mail] , 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: [e-mail] 
> [mailto:[e-mail]] 
> 			Sent: Friday, 7 August 2009 12:29 AM
> 			To: Dawson, Martin; 
> [e-mail]; [e-mail]
> 			Cc: [e-mail]
> 			Subject: RE: [Ecrit] HUM on PhoneBCP
> 
> 			 
> 
> 			Hi Martin, 
> 
> 			 
> 
> 			See comments inline [[LLi]].
> 
> 			 
> 
> 			 
> 
> 			Laura
> 
> 				From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dawson, Martin
> 				Sent: Wednesday, August 05, 
> 2009 11:00 AM
> 				To: Jesske, Roland; [e-mail]
> 				Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 				Hi Roland,
> 
> 				 
> 
> 				I think what you're saying is 
> that you don't think that Germany will go on to implement 
> full ECRIT support but will peg development at an interim phase. 
> 				[[LLi]]  We don't know how the 
> realtime application networks or EC will look like in 20 
> years. Roland's answer only applies to the next 5 to 10 years. 
> 
> 				 
> 
> 				 That would be disappointing - 
> not least because full ECRIT compliance would ultimately 
> decrease the overhead associated with emergency service 
> support for operators as well as providing a more universal service.
> 				
> 				[[LLi]]  This may be true for 
> "green field" ISPs and VSPs but not for incumbent carriers 
> with existing infrastructure.  And universal service is not a 
> requirement for us. Neither the German regulator requires it 
> nor is it a busines case.   
> 
> 				 
> 
> 				Nevertheless, I don't think 
> that decision invalidates the BCP; 
> 				[[LLi]]  We think it does, 
> because some of the requirements are not flexible enough to 
> cover the deployments within the next years.  The BCP should 
> be more flexible:  
> 
> 				·         Allow additional 
> location identifiers  
> 
> 				·         Allow AN operated LOST 
> 
> 				·         Provide a way to 
> enable LOST-query based on national or domain-specific 
> location identifier. One posiblility is to allow the LIS to 
> query the LOST , but there are also other alternatives.  
> 
> 				·         Allow and describe 
> also network-centric, not only ED-centric architectures. If I 
>  remember correctly, John Medland from BT also recomended to 
> use a more network- centric architecture, at least for the 
> next years. 
> 
> 				 
> 
> 				I think it just means that the 
> German regulator and technical advisory committees would 
> point out the subset aspects of compliance that would be 
> applicable to that jurisdiction.  
> 				[[LLi]]  Again, the draft is 
> not flexible enough for it.  If the BCP contains requirements 
> which are not realistic, people will just discard the BCP and 
> implement proprietary stuff. My expectation from a standard 
> body is to define protocols and architecture which people are 
> willing to implement in their network or products , not only 
> in the lab.
> 
> 				 
> 
> 				[[LLi]]  
> 
> 				We are not against the draft in 
> principle. ECRIT provides  us with very valuable 
> specifications as LbyR, HELD, identity extensions. But 
> targeting an architecture which requires everbody to invest 
> without a business case will not help the draft in the end, 
> also if it becomes a BCP.  It would make sense to make it 
> more flexible so people are willing to adopt it.    
> 
> 				 
> 
> 				 Actually, based on your 
> description below, the NENA i2 architecture would probably be 
> a more straightforward baseline for analysis - as has been 
> done in the UK and Canada. Of course, it's generally 
> recognized as only an interim step, even in those jurisdictions.
> 
> 				Other comments below.
> 
> 				 
> 
> 				Cheers,
> 
> 				Martin
> 
> 				 
> 
> ________________________________
> 
> 				From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> 				Sent: Wednesday, 5 August 2009 6:19 PM
> 				To: [e-mail]
> 				Subject: Re: [Ecrit] HUM on PhoneBCP
> 
> 				 
> 
> 				 
> 
> 				Dear all, 
> 				We would like the document to 
> become a BCP as soon as possible so the group can move on 
> with other documents related to emergency calling based on 
> location-by-reference and ED's IP-address. 
> 
> 				[[MCD]] I think you might mean 
> "identity extensions" rather than location-by-reference 
> because LbyR still requires the ED to obtain the reference - 
> e.g. by HELD.
> 				[[LLi]] We use both, the 
> IP-address as UE identity and LbyR. The SIP-proxy uses the 
> IP-address to query the LIS using HTTP (it's not HELD but 
> SOAP over HTTP, but anyway similar). The LIS responds with a 
> numeric string associated to the caller location, in 
> principle a LbyR and with the PSAP number. The proxy inserts 
> the LbyR into the SIP-message (as P-Asserted-ID because the 
> PSAPs are in PSTN) and routes the message to the PSAP.  It's 
> a low cost solution. 
> 
> 				But we can not HUM for the 
> current form of the document. 
> 
> 				Back to the document: Some 
> requirements are far form being realistic, at least in 
> Germany, some are not realistic at all. Implementing these 
> requirements cost a carrier a lot of money and there is no 
> ROI for it. 
> 
> 				Just a few examples: 
> 
> 				·       Requiring either geo or 
> civic location does not provide carriers with enough 
> flexibility to reuse their existing mechanisms and location 
> databases. Routing of emergency calls is currently done in 
> Germany based on phone area code not on geo or civic 
> location, at least for the fixed network. For mobile networks 
> the cell-id is used in common. This is regulated by the 
> german regulator. 
> 
> 				[[MCD]] How many unique PSAP 
> routes are required in Germany? The US has lots (6000 plus) 
> and Australia has two (and they are redundant so it doesn't 
> matter which one). Presumably geographic information, for 
> PSAP catchment areas, is the basis for determining which area 
> codes are relevant to begin with? After all, an area code is 
> not intrinsically geographic; it's a network routing value. 
> If so, then some geographic discriminator is already in play 
> in terms of constructing the area code based routing data 
> (something like zip codes perhaps?) - and in that case, it 
> should be straightforward to by-pass the area code step in 
> the construction of routing that goes the correct PSAP URI. 
> 				[[LLi]] Currently, fixed 
> networks carriers in Germany route the ECs based only on the 
> caller's area code. Sometime in the past, the carriers, the 
> regulator and the PSAPs operators (police, the Red Cross) 
> agreed to do so. This may change in the future, but it will 
> take a quite long time.      
> 
> 				 With nomadic VoIP devices (and 
> it's no good being in denial about this being the norm in the 
> future) area code is no more reliable than it is for 
> conventional mobile phones. And, presumably, area code is not 
> used for conventional cellular emergency call routing?
> 				[[LLi]]  As far as I know, 
> mobile networks use the Cell-ID, not the area code, and have 
> a different table than the fixed network operators. They are 
> not going to change this.  As to the nomadic SIP-users...if 
> we like it or not, very few of our customers use our SIP 
> service nomadic, let alone call EC from their laptop.         
> 
> 				1              LOST as a 
> national, let alone as a global directory is not going to be 
> implemented. The regulator will provide in the web a static 
> table which contains the PSAPs and the area for which they 
> are responsible (one or more area codes). Every carrier has 
> to implement its own routing database for emergency calls. 
> 
> 					[[MCD]] Whatever the 
> carriers implement (and they have to implement something) 
> could just as readily be done using LoST. Then visiting 
> devices, with no association with any local VoIP proxy server 
> would still be able to determine a route to the correct PSAP. 
> Alternatively, as long as the regulator is maintaining a web 
> service with the routing information, why not make that 
> directly accessible using LoST and save the operators the 
> cost of duplicating the service at all?
> 					[[LLi]]  There is a big 
> difference between maintaining a web page with a table which 
> operator can print and implement in their darabases and 
> operating a database which is queried for every emergency 
> call in Germany, must have an availablity of 99,99...% ,  is 
> secure enough...you know. The regulator will not do this.
> 
> 					
> 					2       We have no 
> intention to rely on end devices for location information because: 
> 					·       ED provided 
> location info is not trusted 
> 
> 				[[MCD]] Location by reference 
> mitigates this trust issue. The emergency network can 
> (automatically and before human resources are engaged) assess 
> the source of the reference, and the validity of the location 
> by dereference, without having to trust location provided 
> directly from the ED. There are more sophisticated approaches 
> to trustability even using LbyV - based on digital signatures 
> across appropriate attributes. This WG and Geopriv haven't 
> really got to grips with that... yet.
> 				[[LLi]]  We build the 
> SIP-network and EC now. ED-provided location is needed if EC 
> must work for private and enterprise networks and VPNs.  We 
> have no such regulatory requirements.  And we don't know of 
> any verdor of DSL-EDs which provides today SIP with LbyR and 
> is as cheap as the devices without it. If you do, please let me know. 
> 
> 				The regulator ask us to 
> guarantee that EC works. What if a customer dials 112 and his 
> end device does not send the location? So I have to implement 
> both solutions, with and without ED provided location, anyway.  
> 				1       There are already a lot 
> of existing EDs in usage which don't send location.    
> 
> 				[[MCD]] Quite right. ECRIT 
> doesn't overly concern itself with that interim situation. 
> The UK and Canadian definitions for an interim solution 
> (limiting service to in-country VoIP proxy operators) both 
> assume third-party query via identity-extension to allow the 
> proxy or the VPC to make the query to the LIS. This isn't 
> extensible to universal emergency service access by all 
> visiting devices but it does put the necessary LIS 
> functionality in place as a very good starting point.  It 
> would be a pity if Germany were to cease the evolution there 
> as it would not fulfil the real promise of the Internet and 
> the ECRIT model. 
> 				[[LLi]]  I wonder who will 
> drive and pay for upgrading the interim solutions.  
> Unfortunatelly, it's all about money...
> 
> 				 Think about it; all the 
> complexity of putting location determination infrastructure 
> in place for the purposes of dispatch is done - and then the 
> next, simpler step, of using that to support the routing 
> procedure isn't taken... that would be a waste.
> 				
> 				[[LLi]]  Do you think this is 
> an argument for a product manager? They need a business case.  
> 
> 				 
> 
> 				 
> 
> 				  We don't intend to require 
> our ED-vendors to provide location because it is useless to us.   
> 
> 				We could agree with the 
> document with following changes: 
> 
> 				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 
> 
> 				 
> 
> 				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]
> 
> 				
> 
> 			 
> 
>