Subject: [Ecrit] PSAP Callback - Yet Another Beginning

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 May 2012 13:05:36 +0200

Hi,

Once again, I would like to see whether there is a way for us to move forward on the callback indicator issue.

There are two requirements:

1.       Indicate the callback

2.       Be able to route the callback to the user that made the emergency call

Regarding the indication, it has been suggested that the indicator value is per user, and is provided to the user upon registration.

We also discussed whether the value could change over time, but the problem was that the emg call may be done using an old value, and the callback using a new value (because there was some time between the emg call and the callback, during which the user was given a new value).

To avoid that, the registrar would always provide the same value to a given user.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 May 2012 11:19:07 -0400

I'll repeat my earlier arguments. Maybe I can make them more explicit 
this time. I think we have sufficient mechanism already defined, if it 
is used appropriately. Specifically:

- the UA, when placing an emergency call, can use a temp gruu.
   Its possible to get as many temp gruus as you like, so the UA
   can reserve one for this purpose. This doesn't require any
   new capabilities in registrars.

- when the UA receives a call addressed to a temp gruu that it
   had previously used for an emergency call, it can give it
   special treatment as an emergency callback. It can decide how
   long after the emergency call to grant this special treatment
   as a matter of policy. The special treatment can include dropping
   existing calls, special alerting, etc.

- the PSAP, when placing the emergency callback, can indicate that
   *it* considers this call important using the Priority:emergency.
   If appropriate it can also use other existing headers, such as
   Resource-Priority. It call also use callerprefs to indicate that
   it prefers the real UA and does not wish an automaton.

- middleboxes in the path of the callback can choose to honor the
   Priority:emergency, and use that to condition their behavior.
   For instance, a home proxy could decide that an emergency call
   to a temp gruu should not be diverted. (Though the fact that it is
   to a gruu should typically bypass that anyway.)

- abuses of Priority:emergency by callers can be dealt with by the
   called UA, because it can reject such calls if not to a temp
   gruu previously used for an emergency call. This can cause *some*
   disruption, but only to the extent of handling an incoming INVITE
   and rejecting it. If the frequency of that rises to a level where
   it becomes a problem then it should be dealt with as a DOS attack.

	Thanks,
	Paul

On 5/15/12 7:05 AM, Christer Holmberg wrote:
> 1.Indicate the callback
> 2.Be able to route the callback to the user that made the emergency call
>
> Regarding the indication, it has been suggested that the indicator value
> is per user, and is provided to the user upon registration.
>
> We also discussed whether the value could change over time, but the
> problem was that the emg call may be done using an old value, and the
> callback using a new value (because there was some time between the emg
> call and the callback, during which the user was given a new value).
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: John-Luc Bakker <[email-masked]>
Date: Tue, 15 May 2012 16:12:54 +0000

Hi Paul,

The solution below relies on temporary GRUUs. The UA needs to select a temporary GRUU that is persisted at the PSAP (or CS - PS network entity between UE and PSAP), at the REGISTRAR and at the UE. 

Note that the cause of a prematurely dropped emergency call (i.e. one that requires a call back) may also cause registration information to be removed in the network. Alternatively, the UE may have rebooted causing the prematurely dropped emergency call.

Persistence issues can be addressed.

If there is a solution for persistence, a solution requiring less state to be maintained by UE and (home) network in the eventually of an emergency call back (which is not a regularly happening event) can also be considered. Additionally, some "home" networks do not require support for emergency call backs. Keeping the requirements (i.e. for maintaining state) for emergency call back support in the "serving" network may be preferable.

Kind regards,

	John-Luc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, May 15, 2012 10:19 AM
To: [email-masked]
Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning

I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically:

	Thanks,
	Paul

On 5/15/12 7:05 AM, Christer Holmberg wrote:
> Regarding the indication, it has been suggested that the indicator 
> value is per user, and is provided to the user upon registration.
>
> callback using a new value (because there was some time between the 
> emg call and the callback, during which the user was given a new value).
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 May 2012 12:53:08 -0400

> The solution below relies on temporary GRUUs. The UA needs to select a temporary GRUU that is persisted at the PSAP (or CS - PS network entity between UE and PSAP), at the REGISTRAR and at the UE.

Note that the temp gruu mechanism was specified in such a way that the 
registrar need not persist specific temp gruus.

> Note that the cause of a prematurely dropped emergency call (i.e. one that requires a call back) may also cause registration information to be removed in the network. Alternatively, the UE may have…

You are right that expiration (or removal) of the registration will 
invalidate any temp gruus that have been assigned.

A possible way to address that would be for the PSAP to first try the 
temp gruu, and if that fails, then retry using the permanent gruu. This 
of course has more potential for abuse. (But still limited, because the 
UA can limit special behavior to a time window after an emergency call.) 
In this case the UA might be more hesitant to expedite the call. But it 
could still alert the user, ask the user if he wants to accept this as 
an emergency call, etc. (The middleboxes could still skip special 
handling in this case - leaving the decision to the UA.)

If its unacceptable to raise the bar for answering when the temp gruu 
doesn't work, then forget the temp gruu and use only the permanent gruu. 
Grant emergency behavior at the UA for any incoming call based on 
Priority:emergency and being in a time window following origination of 
an emergency call.

That is not a perfect solution. But I'm not aware of any perfect 
solutions having been proposed.

> If there is a solution for persistence, a solution requiring less state to be maintained by UE and (home) network in the eventually of an emergency call back (which is not a regularly happening eve…

AFAIK state in the PSAP is an acceptable limitation.
And IMO state in the UE is also reasonable, and much more dependable and 
resistant to abuse than mechanisms that don't require state in the UE.

I'm interested in hearing more about situations where the home network 
doesn't have any support for emergency calls but the "serving" network 
does. In that case how do you propose to have the home network avoid 
applying inappropriate services to the callback?

	Thanks,
	Paul