Subject: [Ecrit] Solution Approaches

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 11:11:33 +0200

Hi all,

I would like to share some potential solution approaches with you to 
deal with the problem of not providing precise location to the end host. 
I had a chance to discuss these aspects with Henning face-to-face last 
Friday. Here is a short summary.

Note that the goal was to avoid some form of relationship (e.g., 
business relationship) between the VSP and the ASP/ISP (since this would 
impose a significant deployment problem).

1) Provide enough location information so that the emergency call can be 
routed to the correct PSAP. Precise location information would be 
provided to the PSAP.
This approach was already discussed on the list. We need feedback from, 
for example, Barbara and Laura whether they feel comfortable with this 
approach.

CONSEQUENCE: No changes needed.

2) Provide LbyR + Dial String + PSAP URI to the end host.
We could ignore the potential security vulnerabilities if charging does 
not work on a call-by-call basis.

CONSEQUENCE: No changes needed.

3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a 
reverse LoST lookup to verify the PSAP URI.

CONSEQUENCE: Solution needs to be developed.

4) Provide LbyR + Dial String + PSAP URI to the end host. VSP verifies 
the PSAP URI with the PSAP URIs being flooded (using the LoST 
synchronization mechanism). This mechanism is potentially similar to (3) 
-- details might vary. (3) might use a distributed approach whereas this 
is brute force.

CONSEQUENCE: Solution needs to be developed.

5) Emergency calls are routed via the SIP proxy of the VSP and 
subsequently via a SIP proxy in the ASP/ISP (redirect mode)
SIP Location Conveyance would be used instead of GEOPRIV L7 LCP
Assumption: No service level agreement (or business agreement) between 
VSP and ISP/ASP for this type of SIP emergency message routing required.
 
CONSEQUENCE: No changes needed. Potential problems with SIP Identity 
possible

6) Emergency calls are routed via the SIP proxy of the VSP and 
subsequently via a SIP proxy in the ASP/ISP (no redirect mode)
SIP Location Conveyance would be used instead of GEOPRIV L7 LCP
Assumption: No service level agreement (or business agreement) between 
VSP and ISP/ASP for this type of SIP emergency message routing required.
 
CONSEQUENCE: No changes needed.

7) Decoupled authentication for SIP message routing
Authentication exchange between the end host and the VSP (e.g., TLS to 
obtain a SAML assertion)
Authentication credentials are then added to the SIP emergency message 
that is routed via the SIP proxy in the VSP/ISP.
No service level agreement (or business agreement) between VSP and 
ISP/ASP needed.

CONSEQUENCE: Security extension for this purpose needs to be progressed 
(already available in draft form)

8) Country Code Routing

LIS provides country code to the end host. The end host routes the SIP 
emergency message via the VSP towards a ESRP that corresponds to the 
country code. Then, ESRP fetches more detailed location information todo 
routing within the country.

CONSEQUENCE: No changes to the protocol mechanisms. Deployment of ESRPs 
that work this way are needed. Establishment of ESRP <-> ISP/ASP is more 
difficult than with PSAP <-> ISP/ASP since there are far more nodes to 
consider.

9) Assume end hosts have certs for emergency services; routing via SIP 
proxy in ISP/ASP without traversing VSP in the emergency case.
Existing credential infrastructure can be used when utilizing SIP Cert.

CONSEQUENCE: Architectural aspects need to be developed. A little bit 
more difficult to deploy for VSP. Potential issues with callback (to 
AoR) since end host is not registered with VSP.

10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used to 
authenticate end host
Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter 
SIP interaction.

CONSEQUENCE: Problems with legacy credentials, previously mentioned call 
back problems since end host is not registered with VSP, Diameter SIP 
application would need to be profiled.

Thoughts?

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Apr 2007 07:37:34 -0400

> We could ignore the potential security vulnerabilities if charging  
> does not work on a call-by-call basis.
>

We still would need to define how the UA acquires the dial string and  
PSAP URI.

Using LoST would require a change to LoST (resolving LbyR) and a  
business relationship between the LoST server and the ISP (as well as  
a way to discover the LoST server that can resolve the LbyR).

The alternative is to provide the country code (via LCP/DHCP/...) to  
the UA and have the dial string be looked up via LoST, with the PSAP  
configured via SIP configuration.

Thus, whichever way it's done, this requires additional protocol work.

> 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does  
> a reverse LoST lookup to verify the PSAP URI.
>

This seems to be the same as #2.

>
> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP  
> verifies the PSAP URI with the PSAP URIs being flooded (using the  
> LoST synchronization mechanism). This mechanism is potentially  
> similar to (3) -- details might vary. (3) might use a distributed  
> approach whereas this is brute force.
>

Again, I'd like to separate the verify-URL-is-PSAP problem from the  
location problem. These are completely separate issues, as the  
verification problem only affects the VSP, as it charges for calls.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 15:08:16 +0200

Hi Henning,

> We still would need to define how the UA acquires the dial string and 
Right. I forgot that part.

> Thus, whichever way it's done, this requires additional protocol work.
Correct.

> This seems to be the same as #2.
No. Item (2) just assumes that we ignore the security vulnerability 
(fraud) because we believe it is not a real problem.
For item (3) we believe it is a problem and provide a solution to it.

> verification problem only affects the VSP, as it charges for calls.
There are many aspects that play an important role for the solution:
* location
* verification
* authentication
* deployment considerations
* callback aspects

All these issues have to be considered and cannot be treated 
independently. For some of the solutions we solve the PSAP URI 
verification with call routing through a SIP proxy in the access. This 
also addresses the location aspect.

Ciao
Hannes

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 17 Apr 2007 17:36:07 +0200

> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Dienstag, 17. April 2007 11:12
> An: ECRIT
> Betreff: [Ecrit] Solution Approaches
> 
> 
> Hi all,
> 
> verifies 
> subsequently via a SIP proxy in the ASP/ISP (no redirect 
> mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP
> proxy in ISP/ASP without traversing VSP in the emergency 
> case. Existing credential infrastructure can be used when 
> utilizing SIP Cert.
>

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 17 Apr 2007 17:36:35 +0200

Hannes,

thanks a lot for putting the whole discussion together.  

I can not give you a feedback which is agreed within DT (the internal agreement process would probably take some time). But I roughly discussed the approaches with people working on emergency calling. If we understood the proposal correctly, we have a strong preference for the approach number 8), which could work as follows: 

The ASP/ISP provides to the client the LbyR, the country code (or country and state codes)and the local EC dial string (at login and whenever these data change). 
The client queries LOST and gets back an ESRP URI. 
When the caller dials the emergency calling number, the client queries again the ASP/VSP for the LbyR and the country code and LOST query for the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared secret with the LIS, gets the user location and the correct PSAP and routes the call with the location info to the PSAP (TLS required). (ESRP or a local LOST does load balancing for PSAPs an all this stuff).

Alternatively, the VSPs SIP proxy can do the LOST queries. 

Laura

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Apr 2007 12:02:09 -0400

> For item (3) we believe it is a problem and provide a solution to it.

I'd like to keep these two issues separate.

Fraud impacts the VSP, not the ISP (unless you're talking about  
unauthenticated network access).

Location hiding impacts the ISP, but not the VSP.

>> Again, I'd like to separate the verify-URL-is-PSAP problem from  
>> the location problem. These are completely separate issues, as the  
> verification with call routing through a SIP proxy in the access.  
> This also addresses the location aspect.

I agree that some solutions don't need to worry about URL  
verification, namely if the mapping and routing are done by parties  
trusted by the VSP (or ISP). Also, if you have an ESP, you might  
insert location there, thus avoiding the location hiding problem. But  
these are two special cases.

However, in general, they are independent problems and they don't  
always appear in the same system. For example, DT seems to care about  
not revealing location data, but they don't care if a VSP gets cheated.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Apr 2007 13:01:31 -0400

On Apr 17, 2007, at 11:36 AM, Liess, Laura wrote:

>
> I can not give you a feedback which is agreed within DT (the  
> internal agreement process would probably take some time). But I  
> roughly discussed the approaches with people working on emergency  
> calling. If we understood the proposal correctly, we have a strong  
> preference for the approach number 8), which could work as follows:
>
> The ASP/ISP provides to the client the LbyR, the country code (or  
> country and state codes)and the local EC dial string (at login and  
> whenever these data change).

Once you have the country code (via some location mechanism,  
including L7 or DHCP), LoST will provide you with the dial string, so  
I see no need for yet another mechanism to convey that.

> When the caller dials the emergency calling number, the client  
> queries again the ASP/VSP for the LbyR and the country code and  
> LOST query for the ESRP URI. The VSP routes the call to the ESRP.  
> The ESRP has a shared secret with the LIS, gets the user location  
> and the correct PSAP and routes the call with the location info to  
> the PSAP (TLS required). (ESRP or a local LOST does load balancing  
> for PSAPs an all this stuff).
>

While this works in some way, this has clear drawbacks and consequences:

- It requires a national ESRP.

- It does not allow the caller to verify, even roughly, its current  
address, thus making misroutes more likely. I suppose you could fix  
this by having the test function for emergency dialing read back the  
address to the caller, assuming that doesn't violate the ISPs strict  
confidentiality requirements on the customer's own address.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 16:33:14 -0400

Laura

Although this might work for an access network operator who has a single
ESRP per country, can you accept the fact that it will not be feasible to
have that situation in a country like the U.S., which has 6000 PSAPs and
millions of emergency calls, and without a strong national organization that
could MANDATE that every PSAP use one ESRP?  In such a circumstance, your
proposed solution fails.  Your description requires one ESRP per country.

I suspect this will also fail in countries that have a small number of
PSAPs, but also lack a strong national emergency service infrastructure.  I
am familiar with several countries who could not reasonably organize such a
thing.  In many countries, emergency services is VERY local, and assuming a
single operator of critical infrastructure would be very difficult to
create.

I'd also like to point out that your proposed solution REQUIRES an ESRP.
While I think ESRPs are quite useful, I think requiring that there must be
an entity in the signaling path between the PSAP and the VSP is not such a
good idea.

I think solutions that permit an arbitrary PSAP URI to come from LoST
routing of the complete address is probably going to be necessary.

Brian

> -----Original Message-----
> From: Liess, Laura [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 11:37 AM
> To: [email-masked]; [email-masked]
> Subject: AW: [Ecrit] Solution Approaches
> 
> 
> Hannes,
> 
> I can not give you a feedback which is agreed within DT (the internal
> agreement process would probably take some time). But I roughly discussed
> the approaches with people working on emergency calling. If we understood
> the proposal correctly, we have a strong preference for the approach
> number 8), which could work as follows:
> 
> The ASP/ISP provides to the client the LbyR, the country code (or country
> and state codes)and the local EC dial string (at login and whenever these
> data change).
> When the caller dials the emergency calling number, the client queries
> again the ASP/VSP for the LbyR and the country code and LOST query for the
> ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared
> secret with the LIS, gets the user location and the correct PSAP and
> routes the call with the location info to the PSAP (TLS required). (ESRP
> or a local LOST does load balancing for PSAPs an all this stuff).
>

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 17 Apr 2007 22:51:00 +0200

> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Dienstag, 17. April 2007 19:02
> An: Liess, Laura
> Cc: [email-masked]
> Betreff: Re: AW: [Ecrit] Solution Approaches
> >

This is true and LOST is definitively the best way to get the dial string. I overlooked it. 

> confidentiality requirements on the customer's own address.

I am aware of the drawbacks. But I didn't see any other solution we can live with. Not only because of the location hiding issue, but also because providing a more accurate location information for every end device requires much more performant mechanisms than those we have today. Today, the location information is provided by the system only for emergency calls where the caller is not able to talk to the call taker. Providing it at every login is another order of magnitude. I was told that replacing the current mechanism requires changes in the whole backend infrastructure and would cost millions. Nobody is willing to spend so much money without a business case.

> 
> 
> 
> >
> >>
> >> 8) Country Code Routing
> >>
> >> LIS provides country code to the end host. The end host routes the 
> >> SIP emergency message via the VSP towards a ESRP that 
> corresponds to 
> >> the country code. Then, ESRP fetches more detailed location
> >> information todo
> >> CONSEQUENCE: No changes to the protocol mechanisms. Deployment of 
> >> ESRPs that work this way are needed. Establishment of ESRP <->
> >> ISP/ASP is more

---

From: "Desjardins, Pierre" <[email-masked]>
Date: Tue, 17 Apr 2007 17:01:57 -0400

Brian,

In your response below you state "requiring that there must be an entity in the signaling path between the PSAP and the VSP is not such a good idea".

This seems to be contradictary to what we have been envisioning for NENA i3 -- where ESINet calls reach the PSAP through at least one ESRP (which handles congestion control and other policies for the PSAP).

All I am interested in here is not having to deal with multiple interfaces at the PSAP. 

-pier  

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 4:33 PM
To: 'Liess, Laura'; [email-masked]; [email-masked]
Subject: RE: [Ecrit] Solution Approaches

Laura

Although this might work for an access network operator who has a single ESRP per country, can you accept the fact that it will not be feasible to have that situation in a country like the U.S., which has 6000 PSAPs and millions of emergency calls, and without a strong national organization that could MANDATE that every PSAP use one ESRP?  In such a circumstance, your proposed solution fails.  Your description requires one ESRP per country.

I suspect this will also fail in countries that have a small number of PSAPs, but also lack a strong national emergency service infrastructure.  I am familiar with several countries who could not reasonably organize such a thing.  In many countries, emergency services is VERY local, and assuming a single operator of critical infrastructure would be very difficult to create.

I'd also like to point out that your proposed solution REQUIRES an ESRP.
While I think ESRPs are quite useful, I think requiring that there must be an entity in the signaling path between the PSAP and the VSP is not such a good idea.

I think solutions that permit an arbitrary PSAP URI to come from LoST routing of the complete address is probably going to be necessary.

Brian

> agreement process would probably take some time). But I roughly 
> discussed the approaches with people working on emergency calling. If 
> we understood the proposal correctly, we have a strong preference for 
> the approach number 8), which could work as follows:
> 
> again the ASP/VSP for the LbyR and the country code and LOST query for 
> the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a 
> shared secret with the LIS, gets the user location and the correct 
> PSAP and routes the call with the location info to the PSAP (TLS 
> required). (ESRP or a local LOST does load balancing for PSAPs an all this stuff).
> 
> > I had a chance to discuss these aspects with Henning face-to-face 
> > last Friday. Here is a short summary.
> >
> > business relationship) between the VSP and the ASP/ISP (since this 
> > would impose a significant deployment problem).
> >
> > 1) Provide enough location information so that the emergency call 
> > can be routed to the correct PSAP. Precise location information 
> > would be provided to the PSAP.
> > This approach was already discussed on the list. We need feedback 
> > from, for example, Barbara and Laura whether they feel comfortable 
> > with this approach.
> >
> > similar to (3)
> > -- details might vary. (3) might use a distributed approach whereas 
> > this is brute force.
> >
> > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP 
> > Location Conveyance would be used instead of GEOPRIV L7 LCP
> > 7) Decoupled authentication for SIP message routing Authentication 
> > exchange between the end host and the VSP (e.g., TLS to obtain a 
> > SAML assertion) Authentication credentials are then added to the SIP 
> > emergency message that is routed via the SIP proxy in the VSP/ISP.
> > CONSEQUENCE: Security extension for this purpose needs to be 
> > progressed (already available in draft form)
> >
> > 8) Country Code Routing
> >
> > SIP emergency message via the VSP towards a ESRP that corresponds to 
> > information todo routing within the country.
> >
> > that work this way are needed. Establishment of ESRP <-> ISP/ASP is 
> > more difficult than with PSAP <-> ISP/ASP since there are far more 
> > nodes to consider.
> >
> > 9) Assume end hosts have certs for emergency services; routing via 
> > SIP proxy in ISP/ASP without traversing VSP in the emergency case. 
> > CONSEQUENCE: Architectural aspects need to be developed. A little 
> > bit more difficult to deploy for VSP. Potential issues with callback 
> > (to
> > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used 
> > to authenticate end host
> > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP 
> > Diameter SIP interaction.
> >
> > CONSEQUENCE: Problems with legacy credentials, previously mentioned 
> > call back problems since end host is not registered with VSP, 
> > Diameter SIP application would need to be profiled.
> >
> > Thoughts?
> >
> > Ciao
> > Hannes
> >
> >

---

From: "Liess, Laura" <[email-masked]>
Date: Tue, 17 Apr 2007 23:11:10 +0200

Brian, 

then, what about this? 
The ASP/ISP provides the client with the LbyR and a SIP URI of a node  which has the credentials to get the location from the LIS. This node may be a PSAP, an ESRP or a SIP Proxy in the access network. 

Otherwise we probably need more than one approach. 

Laura

> Von: Brian Rosen [mailto:[email-masked]] 
> Gesendet: Dienstag, 17. April 2007 22:33
> An: Liess, Laura; [email-masked]; [email-masked]
> Betreff: RE: [Ecrit] Solution Approaches
> 
> 
> Laura
> 
> Although this might work for an access network operator who 
> has a single ESRP per country, can you accept the fact that 
> it will not be feasible to have that situation in a country 
> like the U.S., which has 6000 PSAPs and millions of emergency 
> calls, and without a strong national organization that could 
> MANDATE that every PSAP use one ESRP?  In such a 
> circumstance, your proposed solution fails.  Your description 
> requires one ESRP per country.
> 
> I suspect this will also fail in countries that have a small 
> number of PSAPs, but also lack a strong national emergency 
> service infrastructure.  I am familiar with several countries 
> who could not reasonably organize such a thing.  In many 
> countries, emergency services is VERY local, and assuming a 
> single operator of critical infrastructure would be very 
> difficult to create.
> 
> I'd also like to point out that your proposed solution 
> REQUIRES an ESRP. While I think ESRPs are quite useful, I 
> think requiring that there must be an entity in the signaling 
> path between the PSAP and the VSP is not such a good idea.
> 
> I think solutions that permit an arbitrary PSAP URI to come 
> from LoST routing of the complete address is probably going 
> to be necessary.
> 
> Brian
> 
> > whenever these data change). The client queries LOST and 
> gets back an 
> > ESRP URI. When the caller dials the emergency calling number, the 
> > client queries again the ASP/VSP for the LbyR and the 
> country code and 
> > LOST query for the ESRP URI. The VSP routes the call to the 
> ESRP. The 
> > ESRP has a shared secret with the LIS, gets the user 
> location and the 
> > correct PSAP and routes the call with the location info to the PSAP 
> > (TLS required). (ESRP or a local LOST does load balancing 
> for PSAPs an 
> > all this stuff).
> > 
> > > deal with the problem of not providing precise location 
> to the end 
> > > host. I had a chance to discuss these aspects with Henning
> > > face-to-face last
> We could 
> > > ignore the potential security vulnerabilities if charging does
> Authentication 
> > > exchange between the end host and the VSP (e.g., TLS to
> > > obtain a SAML assertion)
> > > SIP proxy in ISP/ASP without traversing VSP in the emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Apr 2007 17:17:36 -0400

On Apr 17, 2007, at 4:51 PM, Liess, Laura wrote:

>
> I am aware of the drawbacks. But I didn't see any other solution we  
> can live with. Not only because of the location hiding issue, but  
> also because providing a more accurate location information for  
> every end device requires much more performant mechanisms than  
> those we have today. Today, the location information is provided by  
> the system only for emergency calls where the caller is not able to  
> talk to the call taker. Providing it at every login is another  
> order of magnitude. I was told that replacing the current mechanism  
> requires changes in the whole backend infrastructure and would cost  
> millions. Nobody is willing to spend so much money without a  
> business case.
>

I obviously don't know the DT infrastructure, but I'm having a hard  
time believing the 'millions' part. A low-end web server can handle  
hundreds of request a second, particularly of the simple kind needed  
for HELD and similar protocols. Let's just say 100 requests/sec. (Our  
LoST server handles 180 req/sec., including a more elaborate database  
lookup.) This yields roughly 8 million customers for each server,  
assuming a once-a-day login (obviously, most hard phones and ATA  
devices would remain connected for much longer, without a reboot, but  
I don't know what the ratio between soft and hardphones would be. Our  
hard phones get rebooted when there's a software update, every six  
months or so.). Even assuming that DT has 80 million DSL customers  
that have VoIP, this would be ten servers, which cost (retail, with  
bandwidth and server rental) about $2000/month. Or, expressed  
differently, the incremental cost per customer is $0.000025 per month.

I realize that there's a software development cost, but I'm  
suspecting that this isn't affected much by how often the system is  
being queried.

If you'll pay millions for this server infrastructure, maybe I should  
offer our implementation services to DT...

(Here, the modern server could simply be the caching front-end for  
the existing system.)

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 17 Apr 2007 17:21:19 -0400

Laura, 

> I am aware of the drawbacks. But I didn't see any other 
> solution we can live with. Not only because of the location 
> hiding issue, but also because providing a more accurate 
> location information for every end device requires much more 
> performant mechanisms than those we have today. Today, the 
> location information is provided by the system only for 
> emergency calls where the caller is not able to talk to the 
> call taker. Providing it at every login is another order of 
> magnitude. I was told that replacing the current mechanism 
> requires changes in the whole backend infrastructure and 
> would cost millions. Nobody is willing to spend so much money 
> without a business case.

Could you provide some more context here?  I'm curious of the environment
where providing location to an end-point is expensive.  Wireless?  Wireline
Broadband?

Thanks,

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 17:29:51 -0400

I think it will be common, I think it will not be universal, and attempts to
make it universal will lead to problems.

The best example in the U.S. is probably New York City.  There is unlikely
to be a New York State ESRP between the VSP and the New York City PSAP.
It's big enough, and "powerful" in the political sense, to have a direct
connection without an ESRP.

Brian

> From: Desjardins, Pierre [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 5:02 PM
> To: Brian Rosen
> Cc: Liess, Laura; [email-masked]; [email-masked]
> In your response below you state "requiring that there must be an entity
> in the signaling path between the PSAP and the VSP is not such a good
> idea".
> 
> This seems to be contradictary to what we have been envisioning for NENA
> i3 -- where ESINet calls reach the PSAP through at least one ESRP (which
> handles congestion control and other policies for the PSAP).
> 
> millions of emergency calls, and without a strong national organization
> that could MANDATE that every PSAP use one ESRP?  In such a circumstance,
> your proposed solution fails.  Your description requires one ESRP per
> country.
> 
> PSAPs, but also lack a strong national emergency service infrastructure.
> I am familiar with several countries who could not reasonably organize
> such a thing.  In many countries, emergency services is VERY local, and
> assuming a single operator of critical infrastructure would be very
> difficult to create.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 17:57:43 -0400

I don't understand how this would be easier on the access network than
providing the LoST results (e.g. PSAP URI).  That URI may well be an ESRP or
a PSAP URI.  I don't think the access network would want to provide a SIP
proxy; that's getting in the middle of emergency call signaling.

I have this feeling we're talking past one another.

For example, if the access network knows that all of its infrastructure (or
at least all of it served by a single LIS) is in a single country, and that
country has a single ESRP, then it doesn't need to do a LoST lookup; the
result is always a constant to it; the "PSAP URI" is always the ESRP, the
dialstring is always the same, and the boundary is always the same.  This
makes it very simple if the access network is in such a situation.  Many
access networks will be in that situation.  It won't need to determine the
fine grained location until a PSAP asks for it.

Even in the U.S. with our crazy patchwork of PSAPs and odd boundaries, many
of the LIS service areas will be totally within one ESRP/PSAP boundary, and
no LoST access or fine grained location determination will be needed until a
PSAP query comes in.

Brian

> Sent: Tuesday, April 17, 2007 5:11 PM
> To: [email-masked]; [email-masked]; [email-masked]
> The ASP/ISP provides the client with the LbyR and a SIP URI of a node
> which has the credentials to get the location from the LIS. This node may
> be a PSAP, an ESRP or a SIP Proxy in the access network.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 09:12:12 +0200

Hi Henning,

~snip~
> - It requires a national ESRP.
That's the main disadvantage of the approach. If you only have the 
country code available then you essentially need to fall-back to such a 
concept.
For cases where you have more location information available you 
obviously do not need to route your calls through this ESRP.

~snip

Ciao
Hannes

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 18 Apr 2007 10:16:19 +0200

Laura,

In your proposal, you have one ESRP per country (or state)?

Or am I missing something?

Richard

> Sent: Tuesday, April 17, 2007 5:37 PM

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 10:42:14 +0200

Yes.
(but it does not need to be a single physical box)

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 18 Apr 2007 12:40:34 +0200

As far as I understood, the problem is not buying the web server, but the todays T-Com Infrastructure being distributed between many different databases from different manufacturers, operated by different DT departaments, a lot of interfaces (many proprietary). It seems to be quite costly to change this, at least this is what I was told (I don't work myself in this area, so I have to believe what they tell me...). 

Sorry for not having better news...

> Gesendet: Dienstag, 17. April 2007 23:18
> An: Liess, Laura
> Cc: [email-masked]
> Betreff: Re: AW: AW: [Ecrit] Solution Approaches
> 
> 
> 
> would cost

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 08:14:53 -0400

Given your description, I don't see how reducing the request rate is  
going to help, unless your system is essentially manual, i.e., an  
operator looks at various green-screen terminals and tries to figure  
out where somebody is. Otherwise, you could just export the  
information periodically to the modern infrastructure and never have  
the actual location request touch that infrastructure. (Existing US  
MSAGs and ALI databases are also not updated in real time, so such  
export would simply mimic the limitations of the existing  
infrastructure.)

I have to admit that I find this discussion somewhat frustrating. We  
are discussing making major changes, reducing reliability and adding  
costs to everyone's implementation, based on second and third-hand  
information about infrastructure in one carrier, where it is not even  
clear that such changes will address the underlying root cause.

Henning

On Apr 18, 2007, at 6:40 AM, Liess, Laura wrote:

> As far as I understood, the problem is not buying the web server,  
> but the todays T-Com Infrastructure being distributed between many  
> different databases from different manufacturers, operated by  
> different DT departaments, a lot of interfaces (many proprietary).  
> It seems to be quite costly to change this, at least this is what I  
> was told (I don't work myself in this area, so I have to believe  
> what they tell me...).
>

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 18 Apr 2007 14:57:01 +0200

Mark,

the environnment is the IP-Plattform for for fixed access wich has grown over years, beginning with IP over phone lines, then fixed broadband, currently WiFi hotspots are added.  

Laura

> Von: Marc Linsner [mailto:[email-masked]] 
> Gesendet: Dienstag, 17. April 2007 23:21
> An: Liess, Laura
> Cc: [email-masked]
> Betreff: RE: AW: [Ecrit] Solution Approaches
> 
> 
> Laura, 
> 
> 
> Could you provide some more context here?  I'm curious of the 
> environment where providing location to an end-point is 
> expensive.  Wireless?  Wireline Broadband?
> 
> 
> Thanks,
> 
> -Marc-
> 
>

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 18 Apr 2007 16:39:58 +0200

Brian,
I am only trying to find something that works for both situations, a)the VSP gets a country-code-level location (country code or ESRP URI) and b) VSP gets a more detailed location (country and city or more or a local PSAP URI). 

Laura   

> Gesendet: Dienstag, 17. April 2007 23:58
> I don't understand how this would be easier on the access 
> network than providing the LoST results (e.g. PSAP URI).  
> That URI may well be an ESRP or a PSAP URI.  I don't think 
> the access network would want to provide a SIP
> For example, if the access network knows that all of its 
> infrastructure (or at least all of it served by a single LIS) 
> is in a single country, and that country has a single ESRP, 
> then it doesn't need to do a LoST lookup; the result is 
> always a constant to it; the "PSAP URI" is always the ESRP, 
> the dialstring is always the same, and the boundary is always 
> the same.  This makes it very simple if the access network is 
> in such a situation.  Many access networks will be in that 
> situation.  It won't need to determine the fine grained 
> location until a PSAP asks for it.
> 
> Even in the U.S. with our crazy patchwork of PSAPs and odd 
> boundaries, many of the LIS service areas will be totally 
> within one ESRP/PSAP boundary, and no LoST access or fine 
> grained location determination will be needed until a PSAP 
> query comes in.
> 
> Brian
> 
> > which has the credentials to get the location from the LIS. 
> This node 
> > may be a PSAP, an ESRP or a SIP Proxy in the access network.
> > 
> > > Although this might work for an access network operator who has a 
> > > single ESRP per country, can you accept the fact that it 
> will not be 
> > > feasible to have that situation in a country like the U.S., which 
> > > has 6000 PSAPs and millions of emergency calls, and 
> without a strong 
> > > national organization that could MANDATE that every PSAP use one 
> > > ESRP?  In such a circumstance, your proposed solution 
> fails.  Your 
> > > description requires one ESRP per country.
> > >
> > > I suspect this will also fail in countries that have a 
> small number 
> > > of PSAPs, but also lack a strong national emergency service 
> > > infrastructure.  I am familiar with several countries who 
> could not 
> > > reasonably organize such a thing.  In many countries, emergency 
> > > services is VERY local, and assuming a single operator of 
> critical 
> > > infrastructure would be very difficult to create.
> > >
> REQUIRES an 
> > > ESRP. While I think ESRPs are quite useful, I think 
> requiring that 
> > > there must be an entity in the signaling path between the 
> PSAP and 
> > > the VSP is not such a good idea.
> > >
> > > I think solutions that permit an arbitrary PSAP URI to come from 
> > > LoST routing of the complete address is probably going to be 
> > > necessary.
> > >
> > > Brian
> > >
> > > > correct PSAP and routes the call with the location info to the 
> > > > PSAP (TLS required). (ESRP or a local LOST does load balancing
> > > for PSAPs an
> > > > all this stuff).
> > > >
> > > > > face-to-face last Friday. Here is a short summary.
> > > > >
> > > > > 1) Provide enough location information so that the emergency 
> > > > > call can be routed to the correct PSAP. Precise location 
> > > > > information would be provided to the PSAP. This approach was 
> > > > > already discussed on the list. We need feedback from,
> > > > > verifies the PSAP URI with the PSAP URIs being flooded (using 
> > > > > the LoST synchronization mechanism). This mechanism is 
> > > > > potentially similar to (3)
> > > > > -- details might vary. (3) might use a distributed approach 
> > > > > whereas this is brute force.
> > > > >
> > > > > VSP and ISP/ASP for this type of SIP emergency 
> message routing 
> > > > > required.
> > > > >
> > > > > mode) SIP Location Conveyance would be used instead 
> of GEOPRIV 
> > > > > L7 LCP
> > > > > VSP and ISP/ASP for this type of SIP emergency 
> message routing 
> > > > > required.
> > > > >
> > > > > SAML assertion) Authentication credentials are then 
> added to the 
> > > > > SIP emergency message
> > > > > CONSEQUENCE: No changes to the protocol mechanisms. 
> Deployment 
> > > > > of ESRPs that work this way are needed. Establishment of ESRP 
> > > > > <-> ISP/ASP is more difficult than with PSAP <-> 
> ISP/ASP since 
> > > > > there are far more nodes to
> > > > > consider.
> > > > >
> > > > > CONSEQUENCE: Architectural aspects need to be developed. A 
> > > > > little bit more difficult to deploy for VSP. Potential issues
> > > with callback
> > > > > (to
> > > > > [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > >
> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> > >
> > >

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 18 Apr 2007 20:15:06 +0200

Richard,

currently, our own SIP-proxy routes emergency calls comming from our IP-access network to the old PSTN PSAPs.  Currently we  don't have or plan neither LOST nor ESRP nor IP PSAPs. We just assume for Germany national ESRP would be a solution all main players can live with. 
Laura

> Von: Stastny Richard [mailto:[email-masked]]
> Gesendet: Mittwoch, 18. April 2007 10:16
> > > ignore the potential security vulnerabilities if charging does not 
> > > work on a call-by-call basis.
> > >
> > > SAML assertion) Authentication credentials are then added to the 
> > > SIP emergency message

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 14:28:46 -0400

Laura,

it would be most helpful if DT could implement a pseudo-servers at  
least, i.e., an LCP that always returns the geo boundaries of Germany  
(or DE in civic) and, for its own customers at least, a LoST server  
that always returns the address of the ESRP and '1-1-2' as the  
service number. Other VSPs can obviously run their own LoST servers.

That way, software and hardware not made in Germany can function  
normally, while imposing trivial cost on DT. Would that be something  
that you'd consider?

Otherwise, we lose one of the core objectives of the whole ECRIT  
work, namely the ability to plug in a device and make an emergency  
call, without custom software development or manual configuration.

(Given that policing is a state, rather than federal, function in  
Germany, I'm actually surprised that you'll find somebody to operate  
the ESRP, but maybe the Bundeskriminalamt or Innenministerium would  
do that?)

Henning

On Apr 18, 2007, at 2:15 PM, Liess, Laura wrote:

> Richard,
>
> currently, our own SIP-proxy routes emergency calls comming from  
> our IP-access network to the old PSTN PSAPs.  Currently we  don't  
> have or plan neither LOST nor ESRP nor IP PSAPs. We just assume for  
> Germany national ESRP would be a solution all main players can live  
> with.
> Laura

---

From: "Liess, Laura" <[email-masked]>
Date: Wed, 18 Apr 2007 23:05:51 +0200

Henning,

> normally, while imposing trivial cost on DT. Would that be something  

Speaking for myself, I would realy like very much to see this happen. 

I can not make any promise for DT. But I could imagine them providing
this service as a free add-on to DT access customers. DT providing ESRP
services for people using Skype and other ASP/ISP's access could be
subject of discussions with the Bundesnetzagentur.  

For my feeling, in Germany we will need ESRPs, national or not and an
operator for them. The today's PSTN PSAPs have phone numbers which can
not be dialed by end users (contains hexadecimal digits). This was a
requirement of the PSAPs operators, that calls can be routing to them
only by the network. I can imagine them not wanting any untrusted SIP
proxy routing calls to them. 

I think, sending the country code and the LbyR to the VSP and providing
LOST and ESRP services is a solution DT could in principle live with,
sending the city to the VSP is not. When the Ecrit direction is more
clear, I can try to convince people to begin talking to the
Bundesnetzagentur about LOST and ESRP and who operates which servers. 

Laura    

> work, namely the ability to plug in a device and domake an emergency

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 17:55:42 -0400

Henning recently made a proposal I agreed with involving an LbyR that when
queried by anyone other than a PSAP or ESRP returns a coarse location
suitable to locate an ESRP OR returns a polygon covering the ESRP/PSAP
service area, which is another way to get the same result.  Do you think
that would be acceptable?

As Henning points out, that solves the location hiding and VSP "PSAP URI"
validation problems with no changes to LCPs or LoST or -conveyance.

Brian

> Sent: Wednesday, April 18, 2007 5:06 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: AW: AW: [Ecrit] Solution Approaches
> 
> Henning,
> 
> 
> > Laura,
> >

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 19 Apr 2007 00:05:13 +0200

Brian,

I think we are OK with it. And I really like it. 
Laura 

> Henning recently made a proposal I agreed with involving an 
> LbyR that when queried by anyone other than a PSAP or ESRP 
> returns a coarse location suitable to locate an ESRP OR 
> returns a polygon covering the ESRP/PSAP service area, which 
> is another way to get the same result.  Do you think that 
> would be acceptable?

> 
> As Henning points out, that solves the location hiding and 
> VSP "PSAP URI" validation problems with no changes to LCPs or 
> LoST or -conveyance.
> 
> Brian
> 
> > > least, i.e., an LCP that always returns the geo boundaries of 
> > > Germany (or DE in civic) and, for its own customers at 
> least, a LoST 
> > > server that always returns the address of the ESRP and '1-1-2' as 
> > > the service number. Other VSPs can obviously run their own LoST 
> > > servers.
> > >
> > this service as a free add-on to DT access customers. DT providing 
> > ESRP services for people using Skype and other ASP/ISP's 
> access could 
> > be subject of discussions with the Bundesnetzagentur.
> > 
> > I think, sending the country code and the LbyR to the VSP and 
> > providing LOST and ESRP services is a solution DT could in 
> principle 
> > live with, sending the city to the VSP is not. When the Ecrit 
> > direction is more clear, I can try to convince people to 
> begin talking 
> > to the Bundesnetzagentur about LOST and ESRP and who operates which 
> > servers.
> > 
> > Laura
> > 
> > >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:13:51 +0200

Hi Laura,

that's also an option. The problem here is that the PSAP does not get 
identity information about the emergency caller since the identity is 
unknown to to the access providers if they happen to use a VSP that is 
different from the ISP/ASP.

In my list of solution approaches I thought that this would be a 
problem. Given the complexity we currently discuss I would suggest 
people to always go for unauthenticated network access and use the local 
SIP proxy.

Ciao
Hannes

Liess, Laura wrote:
>>> I can not give you a feedback which is agreed within DT
>>>       
>> (the internal
>>     
>>> discussed the approaches with people working on emergency 
>>>       
>> calling. If
>>     
>>> we understood the proposal correctly, we have a strong
>>>       
>> preference for
>>     
>> for PSAPs an
>>> all this stuff).
>>>> I would like to share some potential solution approaches
>>>>         
>> with you to
>>     
>>>> business relationship) between the VSP and the ASP/ISP 
>>>>         
>> (since this
>>     
>>>> 3) Provide LbyR + Dial String + PSAP URI to the end host.
>>>>         
>> VSP does a
>>     
>>>> CONSEQUENCE: No changes needed. Potential problems with
>>>>         
>> SIP Identity
>>     
>>>> possible
>>>>
>>>> LIS provides country code to the end host. The end host
>>>>         
>> routes the
>>     
>>>> 9) Assume end hosts have certs for emergency services;
>>>>         
>> routing via
>>     
>>>> bit more difficult to deploy for VSP. Potential issues 
>>>>         
>> with callback
>>     
>>>> (to
>>>> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP
>>>>         
>> application used
>>     
>>>> to authenticate end host
>>>> Assumption: No roaming agreement assumed for ISP/ASP <->
>>>>         
>> VSP Diameter
>>     
>>>> SIP interaction.
>>>>
>>>> CONSEQUENCE: Problems with legacy credentials, previously
>>>>         
>> mentioned
>>

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 19 Apr 2007 22:54:53 +0200

Hannes,

I think there is some misunderstanding here. Our planned Emergency Calling routes only emergency calls from our VoIP and access customers, so we can authenticate the SIP INVITE. A second reason against ASP/ISP SIP Proxy is very bad experience with new clients. The first interoperability tests failed. Probably many emergency calls will not go through due to interoperability problems. 
I like very much Henning's idea to return a coarse location to the client and the fine location to the ESRP/PSAP. I think there is the unique solution all player can live with. 

Laura

routing for not  There is a second reson freanother Another problem with emergency calls being sent to a SIP Proxy in the access is that in the real world from our   I using an ASP/ISP  SIP-Proxy in the the we us the  

> Gesendet: Donnerstag, 19. April 2007 21:14
> An: Liess, Laura
> Cc: [email-masked]; [email-masked]
> > currently, our own SIP-proxy routes emergency calls comming 
> from our 
> > IP-access network to the old PSTN PSAPs.  Currently we  
> don't have or plan neither LOST nor ESRP nor IP PSAPs. We 
> just assume for Germany national ESRP would be a solution all 
> main players can live with.
> > Laura
> >
> >   
> >>>> would be provided to the PSAP. This approach was already 
> discussed 
> >>>> on the list. We need feedback from,
> Deployment of 
> >>>> ISP/ASP is more difficult than with PSAP <-> ISP/ASP since there 
> >>>> are far more nodes to
> >>>> consider.
> >>>>
> >>>> Existing credential infrastructure can be used when 
> utilizing SIP 
> >>>> Cert.
> >>>>