Subject: Re: [Ecrit] Emergency Calls & VoIP Peering

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Feb 2008 08:28:11 -0500

I have some conflicting thoughts on this.  It should be possible for a phone
to send the call itself direct to the PSAP URI.  The emergency call system
should be able to handle that.

On the other hand, carriers are generally thought of as useful partners by
the emergency call system, and a recommendation that they be bypassed won't
be appreciated by those folks even if there is an engineering argument that
it's more efficient.

Part of the reason is track and trace.  Part of the reason is subscriber
name and address.  The big one is identity.  Carriers provide reasonably
verified identity.

So, on balance, I think phonebcp should say, as it does now, that phones
pass emergency calls to wherever they normally pass outbound calls.
Frankly, the number of special processing steps we're asking phones to do
for emergency calls is getting too high.  I'd rather figure out ways to
remove some special processing, not add more.

Presently phones have to:
*Get location and do LoST lookups
*Watch for emergency dial strings
*Add Geolocation headers, PSAP URIs and service urns
*Disable some features
*Not send bye

If anything, that list is too long.  As with most things like it, the more
special stuff you do for emergencies, the less likely it is to actually work
in an emergency.

Generally, I think phones knowing where they are is a good thing in the big
picture, and having the phone do all dial plan interpretation is the right
thing also.  So the real special processing is the last three.  

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, January 31, 2008 11:31 PM
> To: Brian Rosen; Hannes Tschofenig; [email-masked]; ECRIT
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> We need to note the points where we are actually in agreement. Perhaps
> there was an inference that we weren't with respect to the following:
> 
> 1. The access network provider (the one that gets you onto the Internet)
> should not be responsible for providing any kind of emergency call
> processing.
> 
> 2. The access network provider does need to provide a location service
> that can be used for emergency call processing
> 
> 3. The LoST service with the translations for that point of access needs
> to be available from that point of access. Somebody is actually
> responsible for the physical infrastructure that supports it but it
> doesn't have to be the access provider - just so long as it's
> discoverable from the access.
> 
> I am in agreement with these principles - nothing I said below was
> inconsistent with them.
> 
> Direct to PSAP-URI calling is a supported mode of operation, yes? What
> distinguishes between the circumstance where a device does this versus
> trying to send the call through its VSP? It may be because the specific
> implementation of the VoIP client that the caller is using simply
> decides to do that. This includes the possibility that the client
> doesn't know its actually an emergency call and leaves it up to the VSP
> to do the digit analysis. It includes the case where the VoIP client
> doesn't know anything about ECRIT and just sends all calls to the VSP.
> 
> I don't think in this decision that's governed by the nature of the
> access is there? If not, discussion about NATs etc seem irrelevant to
> me. In fact, my standard "nomadic" VoIP service is Skype. In my office,
> our IS masters don't let Skype work. It's very difficult to guarantee
> that arbitrary VSP access is going to work from arbitrary access points.
> It's much simpler to guarantee that SIP calling directly to the relevant
> PSAP URIs for those points of access will always work. I think details
> such as whether an enterprise VoIP server is the thing that makes the
> PSAP call is just that - a detail. In such an environment, the clients
> and the server are part of the same package anyway. It's not at all the
> same situation as bringing Vonage, for example, into the picture when an
> emergency call is made.
> 
> When it comes to phone BCP, it should be quite possible to say that the
> phone client should always work to the local network and direct the call
> directly to the PSAP. This, in my view, is what pure-ECRIT should be
> about. It should also be possible to say that if the phone can only dial
> digits that are processed by the VSP, then subsequent behaviour is out
> of scope (but here's some suggestions). The NENA i2 architecture already
> has this covered and it's being picked up internationally anyway. It's
> an interim architecture; it'll go away as jurisdictions implement LoST
> and IP PSAP services and VoIP clients learn to use those functions. It
> would be preferable that, when the interim solution does disappear, that
> VSPs no longer need to have a role or responsibility for providing
> emergency access. It would be better for all concerned if they did not.
> 
> Here's the logic:
> 
> 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke
> i2.
> 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2
> 3.Phone can find LIS and LoST - call PSAP directly
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 1 February 2008 3:56 AM
> To: Dawson, Martin; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> First my response to the original question:
> 
> IMS is special because the visited network is in the call path.  When
> the
> visited network has active elements in the call path, it makes sense to
> have
> the visited network handle emergency calls.  Note that there are lots
> and
> lots of complications with this.  Take for example, call back.  What you
> want is to have both a Contact URI that will route back to the device
> that
> placed the call, and you need a real AoR you can use to reach the caller
> later on.  The visited network would have to provide both.
> 
> When the visited network is not in the call path, you have to use the
> VSP.
> 
> 
> Then my response to Martin:
> > It's been said that the emergency service wants the subscriber details
> > from the VSP. A caller can have subscriptions to lots of Internet
> > services that also don't need to be involved in the call. Should we
> also
> > make emergency calling dependent on them?
> No.  However, involving the actual carrier that provides the service
> that is
> placing the call is essential.  Bypassing the carrier that provides the
> service that places the call is pretty tough, except in unusual
> circumstances.  IMS is an example of an unusual circumstance because
> they
> put the visited network in the call path.  Very few other systems do
> that.
> 
> I'm very conscious of what we must ask the access network to provide.
> This
> has lots of implications on engineering as well as cost and liability.
> Unless the device itself can locate itself without assistance of the
> access
> network, we ask the access network to provide location (or at least
> location
> assistance).  We ask them to provide access to a LoST server.  I want to
> stop there.  That's all they have to do.
> 
> >
> > I don't think it has to be the same as IMS. IMS requires a
> co-operative
> > E-CSCF that is actually part of the access network. With LoST and a
> > suitable emergency proxy, there doesn't have to be any dependency on
> the
> > access network to also provide call processing.
> IMS is different as discussed above.
> 
> >
> > Not involving the VSP in the call does not mean that the caller cannot
> > provide callback details (in principle, they could provide multiple
> > callback options). I'd also be interested in a discussion around
> > providing an automatic presence subscription from the emergency
> network
> > itself - with a temporary callback number. As long as the emergency
> > calling device is attached to the Internet, it should be able to stay
> > registered with that temporary subscription and also do regular
> location
> > updates to it.
> I think the notion that we can define the characteristics of an
> emergency
> proxy that works for all devices is not feasible.  Let me cite a few
> examples:
> 
> Emergency call from AOL/MSN/Yahoo.  We would have to require the device
> to
> implement SIP/SIMPLE.
> 
> Emergency call from OnStar.  Who is the emergency proxy provider?
> 
> Emergency call from "Help I've fallen and I can't get up" buttons with
> two
> way audio.  They would have to meet all of the phonebcp requirements.
> 
> Call backs are an issue.  You can get a contact URI, but you can't get
> an
> AoR you have any trust in for any call.
> 
> But the biggest problem is that I think any attempt to give the access
> network the obligation and the liability to totally handle emergency
> calls
> will not fly.
> 
> 
> >
> > Many of the most convoluted issues that have arisen in this forum have
> > been around the challenges that having the VSP involved in call
> routing
> > introduces (the need for forest guides etc). Since direct-calling is a
> > valid option, I know I'd prefer an emergency calling client that
> always
> > worked that way.
> 
> 
> 
> --------------------------------------------------------------------------
> ----------------------
> 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]

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Feb 2008 08:56:11 -0500

I think we will have to agree to disagree.  I noticed you ignored identity.

Anyone else think the only way emergency calls should (normally) work is to
have all devices place emergency calls direct to PSAPs with (normally) no
proxies?

Brian

> Sent: Sunday, February 03, 2008 10:20 PM
> Hi Brian,
> This seems to suggest that there's a complexity argument for saying
> phones should pass emergency calls however they "normally" make calls.
> 
> If we have a precept that says it must always be possible to make a call
> directly to the PSAP URI from a given point of access, then also
> supporting call routing via the VSP can only add complexity. Issues such
> as how do VSPs that don't use SIP work, or recognizing dial strings when
> the VSP doesn't know what the intent and regional conventions are, or
> the VSP finding the right LoST server when it's not in a position to
> perform local discovery are all complexities that arise by not sending
> the call directly to the PSAP URI. They are all things that make the
> handling of an emergency call more brittle.
> 
> The question of what is "normal" can only become more fuzzy over time as
> well. Increasingly we just have IP-enabled multimedia devices that can
> have an arbitrary number of service clients/subscriptions hosted on
> them. I think this is really the environment that ECRIT should be
> focussed on. It's the device that should know how to initiate and
> support emergency calling - not the potential multitude of other service
> clients hosted on that device.
> 
> Ideally, all devices should have practically the same implementation
> that knows how to do local location and LoST service discovery and to
> subsequently contact the local emergency service. Dedicated VSP client
> devices could integrate such a reference implementation, provide a
> mechanism to call it, and only invoke VSP-specific emergency handling if
> (as I described below) the local network does not appear to support the
> necessary ECRIT functions. This should result in less complexity over
> time with more and more consistent implementations from the device
> perspective as well as the network perspective. As long as the reference
> client works, then the network is doing the right thing.
> 
> "Track and trace" become Internet access issues. We get to the point
> where we have optimal assurance that the access is local to the
> emergency jurisdiction and we have all the same wherewithal with respect
> to this function as we do with the PSTN - without needing to think that
> VSPs are important to it.
> 
> I think everything that ECRIT has is just about right. I just think that
> the mantra about "normal call processing" has things the wrong way
> around. i.e I have the opposite view to what you expressed, Brian.
> Ultimately, I think VSP involvement should go away - and not actually be
> the recommended approach in perpetuity. The VSP considerations should
> become recommendations that are ultimately deprecated.
> 
> Note - I understand very well that redoing documentation and recanting
> on policy is a demotivator. However, now is always the best time to
> change if we don't have things quite right.
> 
> Cheers,
> Martin
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Saturday, 2 February 2008 12:28 AM
> Subject: Re: [Ecrit] Emergency Calls & VoIP Peering
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 4 Feb 2008 11:40:11 -0500

I think that for many years to come, the "PSAP URI" will be some sort of
"tel uri", which will require the call to be sent to a PSTN gateway.
Currently, there is no way for a SIP client to get a call to the PSTN,
without going through some sort of VSP with a PSTN gateway. PSAP
providers who don't immediately move over to VoIP, should not be
expected to incur the cost of having/maintaining VoIP infrastructure
(i.e., a PSTN gateway) in order for the ecrit architecture to work
properly. Under no circumstances, should the access network be expected
to provide a PSTN gateway.

If the device has all the information needed to properly route the call
to a PSAP, then I don't understand what it is that might break, if a VSP
is asked to route the call. 
I'm looking at Martin's list of potential issues, and I don't really see
how they apply:
> how do VSPs that don't use SIP work
Presumably, if the VSP doesn't do SIP, then the client associated with
that VSP isn't a SIP client. It's highly likely that some random visited
region will only support SIP, so it's unlikely that non-SIP clients will
be supported, with or without the VSP. I don't understand this issue. If
the device does have a SIP client, and that SIP client isn't registered
with any SIP proxy, then I'm fine with saying it's ok for the device to
try to route the call directly.

> recognizing dial strings when
> the VSP doesn't know what the intent and regional conventions are
Direct routing can only work if the device is able to recognize dial
strings. So, if a device recognizes dial strings, and properly forms the
SIP messages (per phonebcp), it's not clear to me why sending the
well-formed SIP message to the VSP (vs. directly) would force the VSP to
have to recognize the original dial string. If the device doesn't
recognize the dial string, then it won't be doing direct routing, in any
case.

> perform local discovery 
Again, we need to only compare the cases of "send call to VSP" vs.
"direct route call" when the device recognizes an emergency call and
knows the route. If the device knows the route, then it shouldn't matter
whether or not the VSP can get to or discover the LoST server. If the
device doesn't know the route, then direct routing won't work, either.

I don't see that any of these potential issues are real issues. Going
back to my original point about needing access to a PSTN gateway in the
foreseeable future, I think it's critical that "initialized" devices
send emergency calls to their configured proxy, as they would with any
other call. I'm happy to suggest that uninitialized devices with
Internet access SHOULD directly route calls.
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Monday, February 04, 2008 8:56 AM
To: 'Dawson, Martin'; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'
Subject: Re: [Ecrit] Emergency Calls & VoIP Peering

I think we will have to agree to disagree.  I noticed you ignored
identity.

Anyone else think the only way emergency calls should (normally) work is
to
have all devices place emergency calls direct to PSAPs with (normally)
no
proxies?

Brian

> On the other hand, carriers are generally thought of as useful
partners
> by
> special stuff you do for emergencies, the less likely it is to
actually
> work
> in an emergency.
> 
> Generally, I think phones knowing where they are is a good thing in
the
> big
> > same situation as bringing Vonage, for example, into the picture
when
> > assistance).  We ask them to provide access to a LoST server.  I
want
> > > introduces (the need for forest guides etc). Since direct-calling
is
> a
------------------------------------------------------------------------
> --
------------------------------------------------------------------------
> --
------------------------------------------------------------------------
--
------------------------------------------------------------------------
--

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 4 Feb 2008 19:20:21 +0100

The access network in 3GPP is the part of the network that provides the
radio access and the first level of mobility management. 

From there you have the access network and part of the core network
providing IP connectivity to the first element that appears at the SIP
layer. That IP connectivity can end you up in the local network or the
home network.

I would suggest you are probably looking for something like IMS local
network.

Regards

Keith 

> Sent: Thursday, January 31, 2008 5:10 PM
> To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; 
> [email-masked]; 'ECRIT'
> I made the same assumption, which I know to be wrong.  Thank 
> you for correcting us.  Is "3GPP Access Network" the right 
> terminology for the kind of network where the visited network 
> provides the E-CSCF?
> 
> Brian
> 
> > From: Stark, Barbara [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2008 12:05 PM
> > To: Dawson, Martin; Hannes Tschofenig; [email-masked]; ECRIT
> > snip...
> > > IMS requires a co-operative
> > > E-CSCF that is actually part of the access network.
> > 
> > This is not true. Please don't confuse "IMS" with "3GPP 
> Access Network"
> > and early 3GPP IMS definitions. They aren't the same. It's 
> absolutely 
> > possible to have an IMS core that exists only on the Internet, and 
> > that makes no assumptions about access networks.
> > Barbara
> > 
> > *****
> > 
> > The information transmitted is intended only for the person 
> or entity 
> > to which it is addressed and may contain confidential, proprietary, 
> > and/or privileged material. Any review, retransmission, 
> dissemination 
> > or other use of, or taking of any action in reliance upon this 
> > information by persons or entities other than the intended 
> recipient 
> > is prohibited. If you received this in error, please contact the 
> > sender and delete the material from all computers. GA622
> > 
> > 
> > 
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> https://www1.ietf.org/mailman/listinfo/ecrit
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Feb 2008 13:35:05 -0500

I'm looking for a term of art when a local access network is IMS aware, and
the local network provides the E-CSCF.  Not all IMS systems do that, right?

Is "IMS local network" a known term of art where I can expect an E-CSCF to
handle emergency calls rather than forwarding to the home domain?

Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, February 04, 2008 1:20 PM
> To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig;
> [email-masked]; ECRIT

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 04 Feb 2008 19:39:51 +0000

My assumption is that "local network" is fairly well understood to mean
"the network with which the IP-CAN to which the user is currently
attached, is associated".  In other words the local network is the
visited network if you're roaming, your home network otherwise.  

Do all IMS networks provide an E-CSCF?  I doubt any do at the moment,
because the standards are pretty new and not all details are resolved.

If there were an E-CSCF in the "IMS local network" I would expect it to
behave per TS 24.229, which indicates that the call is directed to the
PSAP by the E-CSCF and is NOT forwarded to the home network.  

Tim

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Monday, February 04, 2008 12:35 PM
> To: 'DRAGE, Keith (Keith)'; 'Stark, Barbara'; 'Dawson, 
> Martin'; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 6 Feb 2008 17:48:13 -0600

Hi Brian,

Cheers,
Martin

-----Original Message-----

I have some conflicting thoughts on this.  It should be possible for a
phone
to send the call itself direct to the PSAP URI.  The emergency call
system
should be able to handle that.

On the other hand, carriers are generally thought of as useful partners
by
the emergency call system, and a recommendation that they be bypassed
won't
be appreciated by those folks even if there is an engineering argument
that
it's more efficient.

Frankly, the number of special processing steps we're asking phones to
do

If anything, that list is too long.  As with most things like it, the
more
special stuff you do for emergencies, the less likely it is to actually
work
in an emergency.

Generally, I think phones knowing where they are is a good thing in the
big
picture, and having the phone do all dial plan interpretation is the
right
thing also.  So the real special processing is the last three.  

Brian

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 6 Feb 2008 17:48:32 -0600

Hi Barbara,

I certainly agree with the "years to come" sentiment. Some jurisdictions
may provide genuine PSAP URIs quite quickly; others may find it quite
difficult to migrate away from legacy infrastructure.

My sentiment in this thread, however, is focussed on the long term and
what policy should be in the long term. Given the future scenario:

1. I am in Lithuania (Sierra Leone has gotten too crowded) where they
have implemented a national LoST service and PSAP URI(s).
2. I have a device with a number of service clients - including a VSP in
the USA
3. I am using a WiMAX service in Lithuania that is a roaming partner of
my broadband wireless provider in the USA

I authenticated with the WiMAX provider using EAP and based on my home
wireless provider credentials. So, I'm already on the Internet and the
device has already discovered the local LoST service for that point of
access, established a context with the LIS in that access, and cached
the emergency service URI(s).

I need to make an emergency call.

Now - is it more reliable to initiate a SIP session directly to the URI
which is just the other side of the access network or is it better to
send an approximate location to the US VSP (depending on both how the
location-hiding is done in that jurisdiction and how location is
conveyed in the VSP's VoIP protocol) have the VSP recognize it's an
emergency calling situation, try to find the correct LoST server,
re-determine the PSAP URI and proxy the call to the Lithuanian PSAP
(while deciding whether to charge the subscriber for the call)?

The interim situation where PSTN (or general circuit service tandeming)
is required is exactly what i2 tackled. Indeed, the US VSP will probably
have i2 support implemented and use a VPC (or v4/5 redirect/proxy) to
handle the call anyway. This is just to emphasise that once call
handling is given to the VSP, then it all becomes quite VSP-specific in
terms of how the rest of the processing is done. I don't see how ECRIT
can say much about that in the short term (apart from some
recommendations) - and I don't see why VSPs need to be involved in the
long term. Hence my objection to a perpetual policy that says "always
use the VSP if you can".

Brian is wrong when he says I ignored the "identity" issue. I said
earlier in the thread that it's the access that's important for this.
The really important identity information to the jurisdiction accepting
the emergency call is the one associated with my Internet access.

In my example, identity is the WiMAX subscription information. What is
needed is a way to get this information to the PSAP. ECRIT needs this
mechanism anyway - because non-VSP proxied calls (perhaps what you mean
by uninitialized) are definitely in scope and this source of identity
information cannot be ignored. I argue it's actually the most important
piece of identity information because it is actually jurisdictionally
relevant. Indeed the URI associated with a location reference is a good
start for making this information available. It provides a callback to
the access network. All that's necessary is the semantics to request
associated identity information by authorized requestors (PSAPs).

Cheers,
Martin

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Tuesday, 5 February 2008 3:40 AM
To: Brian Rosen; Dawson, Martin; Hannes Tschofenig; [email-masked];
ECRIT

-----Original Message-----

Brian

partners
actually
the
when
want
is

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Feb 2008 16:39:23 -0600

At 06:29 PM 2/4/2008, Roger Marshall wrote:
>built in capabilities could be shown as:
>
>base_reference_client:
>-- includes Location, (either in PIDF-LO or Location URI form), and
>-- dial string analysis
>-- SIP INVITE

Problem: If the client includes location, it does so with the below 
client's geolocation header

>routing_reference_client:
>-- does LoST discovery
>-- does LoST lookups
>-- adds Geolocation header
>-- utilizes PSAP URIs
>-- places Service URNs
>
>This offers a way to abstract the application (e.g., VoIP client), which
>is going to otherwise be hard to control.