Subject: [Speermint] 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

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

---

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

Hi Martin,

thanks for the quick feedback.

Dawson, Martin wrote:
> Good question! And one I tried to have discussed late last year.
>
>   
Really. I must have missed it.

> 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?
>   
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).
> 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.
>   
What do you mean by "suitable emergency proxy"? Who would operate it?

> 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 agree that there are different ways todo the call back.

> 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.
>   
You aren't worried about the lack of identity information. Right?

Ciao
Hannes

> 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,
>
> Ecrit mailing list
> [email-masked]
> https://www1.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]
>
>

---

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: "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...
> > 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: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jan 2008 14:03:23 -0500

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

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Thu, 31 Jan 2008 14:23:05 -0500

Hannes,

There are network situations where the only VSPs involved are the Home
VSP and the PSAP.  Local VSP may be incompatible.  So, the case you cite
must be covered.

Mike

> Sent: Thursday, January 31, 2008 3:29 AM
> Subject: [Speermint] Emergency Calls & VoIP Peering
> 
> 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.
>

---

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:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jan 2008 21:37:23 -0500

Brian Rosen wrote:
> (it's not). 

I know its not. That was the point.

> If a call with sip:[email-masked] is placed from a U.S.

One problem is that the visited proxy doesn't know this is a dial string 
at all. It is a URL. That URL *might* embed a dialstring, and it might 
not. Even if it is a dial string, it might be a call to the phone in 
office 11 on the 9th floor of Acme's office building.

Acme is responsible for the phone, not some US provider. Whether it 
wants to honor emergency numbers in other countries is its business.

> an emergency call, regardless of the domain.

What you are asserting is not just about *dial strings*. What you are 
saying is that any arbitrary string of digits that some locale wants to 
consider an emergency number cannot be the user part of any URI that 
might every be used from that locale.

For instance this means that UAs must be very careful about what they 
encode in the user part of a contact URI, because that might at some 
point be the R-URI in a new call. That is absurd.

The fundamental rule in sip has always been that you must make any 
interpretation of the user part of a sip URI unless you are responsible 
for the domain of that URI. (Or at least are cognizant of the 
conventions used by that domain for the user part.)

	Paul