ecrit@ietf.org
[Top] [All Lists]

Re: [Ecrit] Emergency Calls & VoIP Peering

Subject: Re: [Ecrit] Emergency Calls & VoIP Peering
From: "Brian Rosen"
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

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@xxxxxxxxxx]
> Sent: Sunday, February 03, 2008 10:20 PM
> To: Brian Rosen; Hannes Tschofenig; speermint@xxxxxxxx; ECRIT
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> 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
> 
> -----Original Message-----
> From: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On Behalf
> Of Brian Rosen
> Sent: Saturday, 2 February 2008 12:28 AM
> To: Dawson, Martin; 'Hannes Tschofenig'; speermint@xxxxxxxx; 'ECRIT'
> Subject: Re: [Ecrit] Emergency Calls & VoIP Peering
> 
> 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:Martin.Dawson@xxxxxxxxxx]
> > Sent: Thursday, January 31, 2008 11:31 PM
> > To: Brian Rosen; Hannes Tschofenig; speermint@xxxxxxxx; 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:br@xxxxxxxxxxxxxx]
> > Sent: Friday, 1 February 2008 3:56 AM
> > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@xxxxxxxx; '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
> Ecrit@xxxxxxxx
> http://www.ietf.org/mailman/listinfo/ecrit
> 
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]

_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ecrit

<Prev in Thread] Current Thread [Next in Thread>