Subject: [Ecrit] Later call-back

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 1 Dec 2006 08:58:19 -0500

I'll raise an issue that Hannes has mentioned to me: callback by the  
PSAP later. This is actually a general problem, as it would be nice  
for my home proxy to recognize a callback, as I may have special  
policies for handling such calls (automatic whitelist, bypass call  
treatments such as forwarding to voice mail, etc.)

Since we don't assume that the original emergency call traverses the  
home proxy, this has to be stateless, i.e., the PSAP needs to get all  
the information to convince the home agent that this is indeed an  
(emergency) callback. Thus, in general, the caller needs to provide  
the PSAP with some kind of encrypted token that the home proxy can  
recognize. This does not require setting up a new secret, since the  
Digest secret can be-reused for that.

There seem to be several options:

(1) In-Reply-To: If the call-ID is recognizable as an emergency call,  
the home proxy can perform appropriate call treatments. (For example,  
some encrypted version of this information.) This seems like a kludge.

(2) GRUU: Some special GRUU, with the same basic properties and  
problem as (1).

(3) marked call to Contact or AOR: some kind of "I'm a PSAP"  
certificate, with all the usual deployment problems.

(4) New header or Contact parameter: Basically, the caller provides  
the callee with a token that they can present later to prove that the  
call is "special". This seems closely related to the REFER problem  
and maybe we can re-use some of the same techniques.

Any other suggestions?

Henning

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Dec 2006 20:51:45 -0500

On Dec 1, 2006, at 8:58 AM, Henning Schulzrinne wrote:
> the callee with a token that they can present later to prove that  
> the call is "special". This seems closely related to the REFER  
> problem and maybe we can re-use some of the same techniques.

This, to me, seems to be the most workable solution.

I do worry how such a call back will work with the current peering  
arrangements.  Even when other security mechanisms are in place,  
nearly every VSP locks peers down by IP address.  There would  
actually be nothing wrong with going directly to the UA, except for  
those wonderfully handy NATs.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 1 Dec 2006 16:04:38 -0500

On Dec 1, 2006, at 8:51 PM, Andrew Newton wrote:

>> (4) New header or Contact parameter: Basically, the caller  
>> provides the callee with a token that they can present later to  
>> prove that the call is "special". This seems closely related to  
>> the REFER problem and maybe we can re-use some of the same  
>> techniques.
>

I agree, but it will require SIP/SIPPING work. I looked at RFC 3892  
(Referred-By); while it is indeed similar, it is not directly  
copyable. In this case, the problem may be slightly simpler, since  
the UA and the proxy have a trust relationship, so the UA only has to  
hand something to the PSAP that says "I just made an emergency call".  
Instead of the S/MIME effort in 3892, something as simple as an HMAC  
using the Digest secret suffices.

> those wonderfully handy NATs.

I'm not sure I understand. The idea would be that the PSAP would  
contact the AOR or maybe a GRUU, so it would appear to be a normal  
phone call to the VSP, assuming it accepts any SIP calls at all. The  
only reason for the mechanism I discussed was to avoid that the PSAP  
is auto-forwarded to voicemail due to some call processing rule,  
particularly the PSAP is unlikely to be on the emergency caller's  
whitelist.

The choice of AOR or GRUU probably depends on the circumstances, such  
as whether the PSAP wants to reach the person, regardless of device,  
or the calling device.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Dec 2006 21:29:44 -0500

On Dec 1, 2006, at 4:04 PM, Henning Schulzrinne wrote:

> phone call to the VSP, assuming it accepts any SIP calls at all.

That's exactly the problem.  VSPs don't allow calls from just  
anybody.  That's why SPIT is not a problem.

One  solution is that VSPs should that do this (which is nearly  
everyone) should list a non-ACLed proxy as the contact for emergency  
calls, and access is granted based on the data handed to the PSAP.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 2 Dec 2006 16:56:11 -0500

The VSP has to peer, somehow, with the PSAP, to get the call TO the PSAP.
Whatever works that direction ought to work for a call back.  It may be that
PSAPs use commercial carriers for outbound calls, which might alleviate this
particular problem.

One insight on callback is that there should be two kinds: one that gets
back to the same device.  You use that when you get disconnected.  The other
is for use to get back to the same user, much later for some kind of
followup action.  The former is a GRUU kind of thing, the latter is an AoR.

I think the mechanisms being discussed would apply to either, so long as the
AoR always lead to something that would recognize tokens,

Brian

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, December 01, 2006 9:30 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Later call-back

I'm not sure I understand. The idea would be that the PSAP would contact the
AOR or maybe a GRUU, so it would appear to be a normal phone call to the
VSP, assuming it accepts any SIP calls at all. 

That's exactly the problem. VSPs don't allow calls from just anybody. That's
why SPIT is not a problem.

One solution is that VSPs should that do this (which is nearly everyone)
should list a non-ACLed proxy as the contact for emergency calls, and access
is granted based on the data handed to the PSAP.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sat, 2 Dec 2006 19:57:36 -0500

On Dec 2, 2006, at 4:56 PM, Brian Rosen wrote:

> Whatever works that direction ought to work for a call back.

So every VSP is to peer with every PSAP?  My understanding is that  
there is an intention to have regional entities provide the public  
access for many of the smaller municipal PSAPs.  If that is the case,  
then the PSAPs would have to route back through the regional entity.

>   It may be that

What about non-E.164 peering fabrics such as FWD and Gizmo?

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 4 Dec 2006 10:11:55 +0100

>The VSP has to peer, somehow, with the PSAP, to get the call TO the PSAP.

A minor note: a VSP has not only to peer with THE PSAP, it has to peer with 
ALL PSAPs in the world (and vice versa)

Richard

________________________________________
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, December 02, 2006 10:56 PM
To: 'Andrew Newton'; 'Henning Schulzrinne'
Cc: [email-masked]'
Subject: RE: [Ecrit] Later call-back

The VSP has to peer, somehow, with the PSAP, to get the call TO the PSAP.  Whatever works that direction ought to work for a call back.  It may be that PSAPs use commercial carriers for outbound calls, which might alleviate this particular problem.

One insight on callback is that there should be two kinds: one that gets back to the same device.  You use that when you get disconnected.  The other is for use to get back to the same user, much later for some kind of followup action.  The former is a GRUU kind of thing, the latter is an AoR.

I think the mechanisms being discussed would apply to either, so long as the AoR always lead to something that would recognize tokens,

Brian

________________________________________
From: Andrew Newton [mailto:[email-masked]] 
Sent: Friday, December 01, 2006 9:30 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Later call-back

I'm not sure I understand. The idea would be that the PSAP would contact the AOR or maybe a GRUU, so it would appear to be a normal phone call to the VSP, assuming it accepts any SIP calls at all. 

That's exactly the problem. VSPs don't allow calls from just anybody. That's why SPIT is not a problem.

One solution is that VSPs should that do this (which is nearly everyone) should list a non-ACLed proxy as the contact for emergency calls, and access is granted based on the data handed to the PSAP.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Dec 2006 09:20:04 -0500

> then the PSAPs would have to route back through the regional entity.
Yes, we expect regional entities providing public access.
Yes, call backs could route through those entities.

> What about non-E.164 peering fabrics such as FWD and Gizmo?
An entity that uses the public Internet to peer, would have to accept PSAP
calls from the public Internet

PSAPs will (probably, as above, indirectly) accept calls on the Internet.
We expect most calls will come in via private interconnects with an IP
network the PSAP is connected to.

Brian