Subject: [Ecrit] Emergency Calls & VoIP Peering

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Jan 2008 10:28:49 +0200

Hi all,

I wanted to ask you for your opinion since the following issue has been 
brought forward to me many times already.

One deployment mode for the emergency services architecture is to route 
calls through the user's VoIP provider (VSP) and then towards the PSAP. 
Since the VSP is typically not in the visited network there is obviously 
the problem that the emergency SIP call (not the RTP, which would travel 
directly -- hopefully) needs to be handled properly when it leaves the 
VSP, potentially traverses some other peering networks, and then finally 
hits the PSAP.

Some folks, particularly those with an IMS background, argue that 
"everything" should be done locally at the visited network rather than 
routing the call through the user's VSP where things could potentially 
go wrong along the path between the PSAP and the VSP.

Thoughts about this aspect?

Ciao
Hannes

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 31 Jan 2008 06:34:03 -0600

Good question! And one I tried to have discussed late last year.

I don't see any benefit in involving the VSP - for the caller, the VSP,
or the emergency service.

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?

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.

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.

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.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, 31 January 2008 7:29 PM
To: [email-masked]; ECRIT
Subject: [Ecrit] Emergency Calls & VoIP Peering

Hi all,

hits the PSAP.

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Jan 2008 14:52:11 +0200

Hi Martin,

thanks for the quick feedback.

> Good question! And one I tried to have discussed late last year.
Really. I must have missed it.

> make emergency calling dependent on them?
The idea was that the emergency call works in the same fashion as any 
other call. Normal calls just go via your VSP.
The fact that you could attach identity information is quite useful as 
well (for security reasons).
> access network to also provide call processing.
What do you mean by "suitable emergency proxy"? Who would operate it?

> registered with that temporary subscription and also do regular location
I agree that there are different ways todo the call back.

> valid option, I know I'd prefer an emergency calling client that always
You aren't worried about the lack of identity information. Right?

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 31 Jan 2008 07:11:03 -0600

Hi Hannes,

Responses below. And bed time for me :)

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, 31 January 2008 11:52 PM
To: Dawson, Martin
Cc: [email-masked]; ECRIT
Subject: Re: [Ecrit] Emergency Calls & VoIP Peering

Hi Martin,

The idea was that the emergency call works in the same fashion as any 
other call. Normal calls just go via your VSP.
[[MCD]] Yes - I've heard that too. I haven't seen why that is considered
to be an inherent virtue. I think emergency calling would be more
reliable if the emergency client were somewhat decoupled from the
"normal" VoIP client. A reference implementation of an emergency client
that didn't try to be "interoperable" with VSPs, I am certain, would be
much more robust.

The fact that you could attach identity information is quite useful as 
well (for security reasons).
[[MCD]] Since there's no guarantee of VSP subscriber information meaning
anything at all and since a VSP *doesn't have to be used* anyway. I
don't think that any security is provided.

What do you mean by "suitable emergency proxy"? Who would operate it?
[[MCD]] The emergency network has to provide a route into the emergency
network. Emergency calling can't rely on a VSP being there. Going direct
to the PSAP-URI is a valid scenario. Just as emergency call centres
currently provide an access point on the PSTN, so too would emergency
call centres need to provide the access point for IP telephony.
Excluding VSPs from the call procedure doesn't introduce anything new in
that respect.

You aren't worried about the lack of identity information. Right?
[[MCD]] That's right. First, there's no reliable source of identify
information from VSPs anyway. Secondly, the equivalent of PSTN identity
information is actually the Internet access identity information. We'd
be better off getting that information included (via the PIDF-LO or
similar mechanism). If someone is on a free access point then, well,
that's the same as someone making an emergency call from a public
telephone. It can be related back to the access provider but the
individual remains anonymous.

Ciao
Hannes

> Thoughts about this aspect?
------------------------------------------------------------------------
------------------------
> this email is prohibited.
------------------------------------------------------------------------
------------------------

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 31 Jan 2008 16:29:10 +0100

The proposal has its benefits but I think it also has its drawbacks. 

In principle, I have no problem with it as long as the there is no obligation for the access network/ISP to provide an emergency proxy or a P-CSCF which must accept emergency calls from unknown clients and make sure that these calls work.

We have now some experience with a life VoIP service at DT, with adding new clients, with interoperability and NAT traversal problems. We definitively don't want to deal with unknown clients and all these problems for emergency calls. I think PSAPs will not want to deal directly with clients, either. But maybe I am wrong. 

The 3GPP people have their architecture with the P-CSCF in the visited network/access network. But I would like to know how many VoIP/IMS  providers already operate or plan to operate P-CSCF in the visited network. DT does not. And without a P-CSCF in the visited network IMS has the same problems as IETF with emergency calls.  

Laura

 
-----Ursprüngliche Nachricht-----
Von: Dawson, Martin [mailto:[email-masked]] 
Gesendet: Donnerstag, 31. Januar 2008 14:11
An: Hannes Tschofenig
Cc: [email-masked]; ECRIT
Betreff: RE: [Ecrit] Emergency Calls & VoIP Peering

Hi Hannes,

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, 31 January 2008 11:52 PM
To: Dawson, Martin
Cc: [email-masked]; ECRIT
Subject: Re: [Ecrit] Emergency Calls & VoIP Peering

Hi Martin,

Ciao
Hannes

---

From: "Nate Wilcox" <[email-masked]>
Date: Thu, 31 Jan 2008 11:23:14 -0500

The originating SIP UA needs to understand how to route a call to the
correct PSAP regardless of their VSP. The proposal within a couple different
PSAP oriented organizations is that it is done by querying an ECRF (LoST
server) using the URN of the service you are requesting (sos in this case)
 in conjunction with the PIDF-LO to determine the correct next hop routing
proxy and this repeats itself as many times as it takes to get to the
correct PSAP. This implies, of course, that the PSAP can accept a SIP call
(and currently only about a dozen do in North America).

As far as the RTP terminating direct at the PSAP call takers UA, that is a
matter of some dicsssion that would probably better be couched by the folks
who are providing the PSAP facing routing and network services. Although
their is considerable merit in using 3PCC for this purpose.....

Nate
On Thu, Jan 31, 2008 at 3:28 AM, Hannes Tschofenig <

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 31 Jan 2008 11:50:17 -0500

I believe that the solutions created by IETF ecrit need to work in any
of the 3 potential scenarios:
1) end device directly routes emergency calls to emergency network
2) access network detects emergency call and routes directly to
emergency network
3) call goes to regular outbound proxy / SIP proxy (as configured in the
device), which ultimately routes the call to the emergency network; this
proxy is most likely provided by a VSP, although it could be an Asterisk
server in my basement.

All 3 are valid, and I expect all 3 to exist in various places in the
world. 

I see nothing that precludes any of these from occurring.

In reading phonebcp, I believe it is expecting a device to send
emergency calls to its regular proxy, as it would for all calls. I think
this is an appropriate behavior. For uninitialized devices (no
successful SIP registration, but they are on the Internet), I would
prefer if the device did try to route directly, rather than go through
some VSP who can't authenticate them anyway. Since the existence of
devices that can route directly can't really be prevented, I think it is
up to the emergency network to determine what treatment to give such
calls. Honestly, I don't see a whole lot of difference between end
devices that can route directly vs. go through the basement Asterisk
server, from a trust perspective.

If a device has logic that directly routes all emergency calls, I see
nothing wrong with this. But I don't think phonebcp should encourage
this. Since phonebcp is still just a BCP, there's nothing that precludes
this behavior, if that's what's wanted.

Access networks that detect, intercept, and directly route emergency
calls will exist. I don't see how that fact changes any of the ecrit
work. I don't think phonebcp should be changed to accommodate this
scenario, since 3GPP does an excellent job of describing how it can
work. I wouldn't expect a 3GPP access network to necessarily abide by
phonebcp -- rather, I would expect it to abide by whatever rules 3GPP
sets forth. IETF shouldn't try to take this over from 3GPP.

Under no circumstances, however, should there be any attempt to mandate
that all access networks abide by 3GPP rules. Access networks will exist
that do not detect emergency calls. We shouldn't be trying to say if
this is good or bad. It simply is and will continue to be. Both types of
access networks will exist, and I would prefer for ecrit to work under
the assumption that an access network cannot detect emergency calls. If
it can, that's fine, and I don't think anything breaks.

Barbara

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, January 31, 2008 3:29 AM
To: [email-masked]; ECRIT
Subject: [Ecrit] Emergency Calls & VoIP Peering

Hi all,

hits the PSAP.

Ciao
Hannes

*****

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jan 2008 11:55:36 -0500

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.  

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

> access network to also provide call processing.
IMS is different as discussed above.

> registered with that temporary subscription and also do regular location
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.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 31 Jan 2008 12:04:46 -0500

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jan 2008 12:10:11 -0500

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
> Subject: RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> snip...
> 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
> 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 31 Jan 2008 15:28:24 -0500

Not really true.

In your last example, suppose 9-1-1 was directory assistance in the U.K.
(it's not).  If a call with sip:[email-masked] is placed from a U.S.
location, then usually it's an emergency call.  

The local (visited) dial string MUST be honored.  The home dial string MAY
be honored.

It is indeed problematic for the UK proxy to do dial plan interpretation
because it doesn't have location unless the phone already knows it's an
emergency call, but never-the-less, 9-1-1 when dialed in the U.S. is always
an emergency call, regardless of the domain.

As a practical matter, some enterprise dial plans change this.  You
sometimes have to dial 9-9-1-1, and that's an emergency call.  I don't think
Martin's ASP proxy could handle that.  

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, January 31, 2008 2:03 PM
> To: Brian Rosen
> Cc: 'Dawson, Martin'; 'Hannes Tschofenig'; [email-masked]; 'ECRIT'
> Subject: Re: [Speermint] RE: [Ecrit] Emergency Calls & VoIP Peering
> 
> 
> 
> Brian Rosen wrote:
> > the visited network handle emergency calls.
> 
> I think that is acceptable *if* the access network has a well defined,
> unambiguous way to discern whether a call is an emergency call or not.
> 
> If the R-URI is <service:sos> then there is no problem at all. If the
> R-URI is <tel:911;phone-context=+1> then again there is no problem. But
> if the R-URI is <sip:[email-masked]> then it is very problematic if a
> visited network in the US decides this is an emergency call because of
> the "911". OTOH the owner of the domain *can* decide this is an
> emergency call based on its understanding of its numbering plan.
> 
> 	Paul
> 
> > Note that there are lots and
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >

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