Subject: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

From: Roger Marshall <[email-masked]>
Date: Tue, 14 Aug 2012 20:14:57 +0000

As an outcome of the Vancouver ECRIT meeting for the -psap-callback draft, the group discussed the use of the Privacy header field value as something that was meant to indicate a PSAP callback.

Now we need to verify what the decisions were concerning that value, and its use - on the list:

Resolve to use "emergency" as the Private header value, since any new (other) value doesn't offer a real advantage.

Does anyone disagree as to wg acceptance of this approach in the meeting?

We need to move this draft forward for use in 3GPP.

Link to draft: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-04
Link to minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-ecrit

-roger marshall.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2012 16:31:16 -0400

I prefer using "emergency", and would be ok with using some new value.

There was some concern expressed at the meeting that "emergency" might 
already be in use for some other, incompatible, situation. I'm inclined 
to think that unlikely, but it may be hard to determine.

If I understood the discussion, it was that for emergency callback the 
presence of the indication should allow to call to complete even in the 
presence of call barring (e.g. service suspended for non-payment). And 
there was then desire to limit who could use the indicator. Presumably 
the SP could filter out "Priority:emergency" except when received from a 
PSAP. But that would mean that other uses of "Priority:emergency" might 
break.

Perhaps the first question in this regard is whether those that would be 
doing this sort of filtering *currently* allow Priority:emergency or if 
they *already* filter it. (E.g. via an SBC.)

For those that don't have the problem with call barring, I think this 
new usage and any existing usage could coexist. So this might just be a 
question for IMS implementers to investigate.

	Thanks,
	Paul

On 8/14/12 4:14 PM, Roger Marshall wrote:
> As an outcome of the Vancouver ECRIT meeting for the –psap-callback
> draft, the group discussed the use of the Privacy header field value as
> something that was meant to indicate a PSAP callback.
>
> Resolve to use “emergency” as the Private header value, since any new
> (other) value doesn’t offer a real advantage.
>
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> privileged and/or confidential. If you are not the intended recipient,
> or responsible for delivering this message to the intended recipient,
> any review, forwarding, dissemination, distribution or copying of this
> communication or any attachment(s) is strictly prohibited. If you have
> received this message in error, please notify the sender immediately,
> and delete it and all attachments from your computer and network.
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2012 22:50:38 +0200

Hi,

So, if there is potential problem with "emergency", why not define a new value? As far as I remember, nobody objected to that.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Tuesday, August 14, 2012 11:31 PM
To: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2012 17:19:58 -0400

> So, if there is potential problem with "emergency", why not define a new value? As far as I remember, nobody objected to that.

As I said, I'm *ok* with a new value.
But it offends me to have to add a new value when we already have a 
value "emergency" and this *is* an emergency. It sets a precedent that 
nobody can use predefined values that weren't assigned for their own 
specific case. Its another example of a philosophy that we need to 
signal features or use cases rather than simply assemble basic 
primitives to accomplish features.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 15 Aug 2012 15:13:32 +0200

I would prefer a new value.

This is essentially a new defined usage, and it is unlikely that current use is being made of any existing codepoints for this usage.

Given that, I see no need to try and investigate whether we can reuse an existing codepoint, which may well be used for all sorts of other purposes.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christer Holmberg
> Sent: 14 August 2012 21:51
> To: Paul Kyzivat; [email-masked]
> So, if there is potential problem with "emergency", why not define a new
> value? As far as I remember, nobody objected to that.
> 
> Regards,
> 
> Christer
> 
> > As an outcome of the Vancouver ECRIT meeting for the -psap-callback
> > Resolve to use "emergency" as the Private header value, since any new
> > (other) value doesn't offer a real advantage.
> >

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Aug 2012 09:36:11 -0700

On 14 August 2012 14:19, Paul Kyzivat <[email-masked]> wrote:
> But it offends me to have to add a new value when we already have a value
> "emergency" and this *is* an emergency. It sets a precedent that nobody can
> use predefined values that weren't assigned for their own specific case. Its
> another example of a philosophy that we need to signal features or use cases
> rather than simply assemble basic primitives to accomplish features.

I'm with Paul on this one.  These are just labels that have
essentially arbitrary or context-specific semantics.  This looks very
much like a case where context is everything.

"emergency" is the right word.  The only concern is that it might have
some other meaning.  But those uses are specifically in some other
context.  This is a new context (probably based on identification of
the PSAP, but that's simply an example).

If context provides insufficient information to enable the sorts of
decision that we want to enable, then a new label isn't going to fix
that.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Aug 2012 11:28:25 +0200

Hi,

It is true that some entity in the network needs to verify the context, and that the call comes from a PSAP. But, once that is done, other entities within the same network (trust domain) do not need to do that. 

So, for that reason I think a new value would be good.

Regards,

Christer

________________________________________
From: Martin Thomson [[email-masked]]
Sent: Wednesday, August 15, 2012 7:36 PM
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

---

From: John-Luc Bakker <[email-masked]>
Date: Thu, 16 Aug 2012 15:22:45 +0000

Hi Christer,

What you describe below is a trust domain applicable only to a particular header field's value, right? 
Are you saying only if the new value is present, the UA can derive that the header field value can be trusted as it must have been "subjected to verification" (any other value for that header field cannot be trusted)? 

I need to look deeper into trust domains, as I hadn't realized existing (legacy?) header fields could be subjected to trust domain, based on that header field's value.

I was so far leaning towards Martin's and Paul's position, where they claim "emergency" is the right word.

Regards,

	John-Luc 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, August 16, 2012 4:28 AM
To: Martin Thomson; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

Hi,

Regards,

Christer

On 14 August 2012 14:19, Paul Kyzivat <[email-masked]> wrote:
> signal features or use cases rather than simply assemble basic primitives to accomplish features.

I'm with Paul on this one.  These are just labels that have essentially arbitrary or context-specific semantics.  This looks very much like a case where context is everything.

"emergency" is the right word.  The only concern is that it might have some other meaning.  But those uses are specifically in some other context.  This is a new context (probably based on identification of the PSAP, but that's simply an example).

If context provides insufficient information to enable the sorts of decision that we want to enable, then a new label isn't going to fix that.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---------------------------------------------------------------------
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: Christer Holmberg <[email-masked]>
Date: Fri, 17 Aug 2012 09:52:02 +0200

Hi,

I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PSAP callback.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of John-Luc Bakker [[email-masked]]
Sent: Thursday, August 16, 2012 6:22 PM
To: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

Hi Christer,

Regards,

        John-Luc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, August 16, 2012 4:28 AM
To: Martin Thomson; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2012 11:38:27 -0400

> I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PS…

If you are working within a domain you can use whatever criteria you 
want to decide whether to preserve or remove this header when it comes 
across the boundary of the domain. If you want, the border elements can 
only permit it from PSAPs.

One it is inside the trust domain, it is what it is. If it's 
Priority:emergency, then that's what it is. Something inside the trust 
domain could have put it in. Or something on the boundary of the domain 
might have a different policy to let it in from some class of users 
other than PSAPs.

My point is that it is an emergency call, which might have a high 
probability of being an emergency callback from a PSAP. It isn't 
definitively an emergency callback. And then there needs to be a set of 
policies for how to handle emergency calls. That might include things 
like calling barred numbers that you don't want just anybody to be able 
to do.

Of course this is just a philosophical difference from what you said.

	Thanks,
	Paul

---

From: John-Luc Bakker <[email-masked]>
Date: Mon, 20 Aug 2012 19:38:43 +0000

Folks,

> Does anyone disagree as to wg acceptance of this approach in the meeting?

I haven't understood the position against using "emergency". I am happy to use "emergency" as the Private header value.

Kind regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 17, 2012 10:38 AM
To: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

> I am saying that if the value has been verified, other entities within the trust domain don't need to perform the verification. And, using a new value, those entities will also know that it is a PS…

If you are working within a domain you can use whatever criteria you want to decide whether to preserve or remove this header when it comes across the boundary of the domain. If you want, the border elements can only permit it from PSAPs.

One it is inside the trust domain, it is what it is. If it's Priority:emergency, then that's what it is. Something inside the trust domain could have put it in. Or something on the boundary of the domain might have a different policy to let it in from some class of users other than PSAPs.

My point is that it is an emergency call, which might have a high probability of being an emergency callback from a PSAP. It isn't definitively an emergency callback. And then there needs to be a set of policies for how to handle emergency calls. That might include things like calling barred numbers that you don't want just anybody to be able to do.

	Thanks,
	Paul

>> value "emergency" and this *is* an emergency. It sets a precedent 
>> that nobody can use predefined values that weren't assigned for their 
>> own specific case. Its another example of a philosophy that we need 
>> to signal features or use cases rather than simply assemble basic primitives to accomplish features.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2012 16:19:16 -0400

I don't care much about this decision.

I'd prefer a new one.  My reason is that 3261 says:
It is RECOMMENDED
   that the value of "emergency" only be used when life, limb, or
   property are in imminent danger.

Call backs don't necessarily have that implication. They might, but it also can be much less important.

I think most implementors would view the emergency call as having priority emergency, but not necessarily the call back.  That's why I think it would be better to create a new value.

But, as I said, I don't care much.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Aug 2012 17:44:11 -0400

> I think most implementors would view the emergency call as having priority emergency, but not necessarily the call back.  That's why I think it would be better to create a new value.

Well, if the callback is happening because the emergency call was 
inadvertently disconnected, then it is still as much an emergency as it 
had been.

And I thought the psap could perform the "callback" without the priority 
if it isn't called for.

And, if it isn't a matter of life, limb, or property in danger, then I 
guess the carrier would be entitled to honor barring.

Also, the quote you cite argues that "emergency" shouldn't be in use for 
other sorts of things.

> But, as I said, I don't care much.

I won't bother to restate my position, since I've already done so enough.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Aug 2012 09:56:41 +0200

Hi,

>>> It is RECOMMENDED that the value of "emergency" only be used when life, limb, or
> Well, if the callback is happening because the emergency call was inadvertently disconnected, then it is still as much an emergency as it had been.
>
> And I thought the psap could perform the "callback" without the priority if it isn't called for.
>
> And, if it isn't a matter of life, limb, or property in danger, then I guess the carrier would be entitled to honor barring.

AFAIK, in countries where special treatment is given to PSAP callbacks, it applies to *ALL* callbacks. Now, in such countries, whether some callbacks would be given different importance, I don't know. But, it means that all callbacks have to be indicated as callbacks.

So, if we think that there are cases where an PSAP would not indicate "emergency" for a PSAP callback, I really think we need a separate value.

Regards,

Christer

>>>> that nobody can use predefined values that weren't assigned for 
>>>> their own specific case. Its another example of a philosophy that 
>>>> we need to signal features or use cases rather than simply assemble basic primitives to accomplish features.
>>>
>>> --------------------------------------------------------------------
>>> - 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: Marc Linsner <[email-masked]>
Date: Tue, 21 Aug 2012 08:16:12 -0400

If a PSAP callback *could* be something other than an emergency, what's
wrong with using less ambigous 'PSAP-callback' as the indicator?

-Marc-

-----Original Message-----
From: "Rosen, Brian" <[email-masked]>
Date: Monday, August 20, 2012 4:19 PM
To: John-Luc Bakker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

>I think most implementors would view the emergency call as having
>priority emergency, but not necessarily the call back.  That's why I
>think it would be better to create a new value.
>
>> I haven't understood the position against using "emergency". I am happy
>>to use "emergency" as the Private header value.
>> 
>> Kind regards,
>> 
>> 	JL
>> 
>>> I am saying that if the value has been verified, other entities within
>>>the trust domain don't need to perform the verification. And, using a
>>>new value, those entities will also know that it is a PSAP callback.
>> 
>>> Are you saying only if the new value is present, the UA can derive
>>>that the header field value can be trusted as it must have been
>>>"subjected to verification" (any other value for that header field
>>>cannot be trusted)?
>>> 
>>> I need to look deeper into trust domains, as I hadn't realized
>>>existing (legacy?) header fields could be subjected to trust domain,
>>>based on that header field's value.
>>> 
>>> It is true that some entity in the network needs to verify the
>>>context, and that the call comes from a PSAP. But, once that is done,
>>>other entities within the same network (trust domain) do not need to do
>>>that.
>>> 
>>> 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.
>> 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Aug 2012 15:32:51 +0300

I agree with you Marc.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 09:43:47 -0400

> So, if we think that there are cases where an PSAP would not indicate "emergency" for a PSAP callback, I really think we need a separate value.

Do you mean that if I make an emergency call today, and then next week 
the psap decides to call me back to take a survey about how nice they 
were on the phone, that should still be treated as an emergency callback 
that gets priority and can bypass barring???

Or if the operator in the PSAP calls to have pizza delivered for lunch 
that should be treated as an emergency callback and work even if the 
pizza place has had its calls barred?

I presume not. Rather, doesn't it need to be on a call by call basis, 
the psap will mark the calls that should be treated as emergency 
callback calls?

If so, then the job of the provider sw is to honor the marking if its 
there, and perhaps to screen which lines are permitted to include the 
marking.

In that case the psap can include "priority:xyz" for those calls it 
considers to be deserving of emergency callback treatment, and not 
include that marking for other calls. And that is the same whether "xyz" 
is "emergency" or "PSAP-callback".

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Aug 2012 10:06:39 -0400

We already differentiate between a call back to the device that sent the call (Contact) vs a call back that happens later and is intended to reach the caller rather than the device (AoR).  I don't think it would be appropriate in most cases to use any kind of special treatment to a call placed a few days after the emergency call placed to the AoR (and Contact is not likely to work at that point).

OTOH, I can't see any hard and fast rules here.

I agree with your premise though - you mark the calls appropriately, regardless of what the marking we decide upon, and policing the marking is going to be important to avoid abuse.

Brian

On Aug 21, 2012, at 9:43 AM, Paul Kyzivat <[email-masked]> wrote:

> Do you mean that if I make an emergency call today, and then next week the psap decides to call me back to take a survey about how nice they were on the phone, that should still be treated as an emergency callback that gets priority and can bypass barring???
> 
> Or if the operator in the PSAP calls to have pizza delivered for lunch that should be treated as an emergency callback and work even if the pizza place has had its calls barred?
> 
> I presume not. Rather, doesn't it need to be on a call by call basis, the psap will mark the calls that should be treated as emergency callback calls?
> 
> If so, then the job of the provider sw is to honor the marking if its there, and perhaps to screen which lines are permitted to include the marking.
> 
> In that case the psap can include "priority:xyz" for those calls it considers to be deserving of emergency callback treatment, and not include that marking for other calls. And that is the same whether "xyz" is "emergency" or "PSAP-callback".
> 
> 	Thanks,
> 	Paul
> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Aug 2012 18:16:38 +0200

Hi,

>>> AFAIK, in countries where special treatment is given to PSAP callbacks, it applies to *ALL* callbacks. Now, in such 
>>> countries, whether some callbacks would be given different importance, I don't know. But, it means that all callbacks have to be indicated as callbacks.
>>

Note that "callback" and "call back" are not necessarily the same thing :)

If the call from PSAP is classified as a "PSAP callback", then it shall get special treatment.

If the call from the PSAP is just another "call back", then it would not get special treatment.

>pizza place has had its calls barred?

In that case it is not a "PSAP callback".

>the psap will mark the calls that should be treated as emergency

I am not saying that ALL calls from a PSAP shall be marked as "PSAP callbacks". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :)

And, in the case the PSAP calls 911, e.g. because the building where the PSAP is located is burning, that would not be marked as a "PSAP callback" either. It would, however, be marked "emergency".

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 13:12:04 -0400

> I am not saying that ALL calls from a PSAP shall be marked as "PSAP callbacks". Only "PSAP callbacks" calls shall be marked as "PSAP callback" :)

OK. Unless somebody else chimes in, I guess this part is clear.
And it would be true regardless of whether the marking is 
"Priority:psap-callback" or "Priority:emergency". Right?

> And, in the case the PSAP calls 911, e.g. because the building where the PSAP is located is burning, that would not be marked as a "PSAP callback" either. It would, however, be marked "emergency".

I guess this raises the question of whether the 911 call might contain 
Priority:emergency, and if so what that means.

Superficially it seems reasonable that an emergency call (and presumably 
a 911 call qualifies) could, and perhaps SHOULD, contain 
Priority:emergency. And if so, does that imply the same semantics as the 
callback case?

The distinction here is not about the priority of the call. It is about 
whether the priority is based on the status of the caller or the callee, 
if that matters.

ISTM that the *call* is equally important regardless of the direction. 
For instance, in the unlikely event that the psap hasn't paid its phone 
bills and has been barred, the 911 call should still go through.

Is it really necessary for the indication of the priority of the call to 
indicate which end the priority applies to???

I don't think so. But if so, then maybe we need:

Priority: caller-emergency
Priority: callee-emergency

The notion of "emergency callback" is just an artifact. The prior 
emergency call is the way in which the psap has learned that the call 
being made is about an ongoing emergency at the callee.

For instance - suppose I call 911 on my home phone and am talking to the 
psap. But then I have to move away from that phone. (The fire is getting 
too close to me.) But I have a cell phone. It would be good if the psap 
could call my phone and have it treated as an "emergency callback". (So 
even if my phone is barred it would work.) And this is better than me 
calling 911 again on my cell phone because even if it isn't barred I 
might not get the same psap or operator.

	Thanks
	Paul

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Aug 2012 20:21:28 +0200

Hi,

> "Priority:psap-callback" or "Priority:emergency". Right?

Well, it depends on whether the PSAP would use "Priority:emergency" for something else than PSAP callback calls (see below). But, it would only use "Priority-psap-callback" for PSAP callback calls.

> I guess this raises the question of whether the 911 call might contain Priority:emergency, and if so what that means.

Ok, but my point was that if the PSAP makes an emergency call itself, it would not be marked as a PSAP callback call. It may still be marked (using whatever mechanism) as an emergency call, though.

> Priority:emergency. And if so, does that imply the same semantics as the

At least I think they are routed differently. An emergency call is routed towards a PSAP, while a callback call is routed towards the caller who made the associated emergency call.

> might not get the same psap or operator.

Yes - and that is what PSAP callback is about :) 

There is no such thing as "emergency callback". There are "emergency calls" and "PSAP callbacks" :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 14:51:12 -0400

> Well, it depends on whether the PSAP would use "Priority:emergency" for something else than PSAP callback calls (see below). But, it would only use "Priority-psap-callback" for PSAP callback calls.

My point was just that in the end it is a label. The label will trigger 
certain behavior, regardless of the name we choose for that.

> At least I think they are routed differently. An emergency call is routed towards a PSAP, while a callback call is routed towards the caller who made the associated emergency call.

The mechanism for emergency calls has been defined to work without use 
of the Priority header. The routing of the call is determined by the 
request URI containing urn:sos. The presence or absence of 
Priority:emergency wouldn't change that.

And maybe the provider wouldn't allow the caller to put in 
Priority:emergency.

But *if* the call *did* have Priority:emergency, and it wasn't stripped 
(because it was the psap calling 911) then presumably it would work the 
same as a psap-callback.

> Yes - and that is what PSAP callback is about :)

AFAIK the assumption has been that a "psap callback" is always in 
conjunction with a prior recent emergency call, and to the same device 
that initiated that call.

What I described above is to a device that isn't the same one that made 
the emergency call, and not even to another device with the same AOR.

Its really a fundamental conceptual difference, even if the same 
mechanisms support both. Its a change to a concept that the psap can 
mark a call (any call it makes) as deserving of this special treatment.

> There is no such thing as "emergency callback". There are "emergency calls" and "PSAP callbacks" :)

Or "calls indicating that the caller wants help with an emergency", and 
"calls indicating that the caller needs to talk to the callee about a 
callee emergency".

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Aug 2012 16:11:52 -0700

On 21 August 2012 10:12, Paul Kyzivat <[email-masked]> wrote:
> whether the priority is based on the status of the caller or the callee, if
> that matters.

Whoa, we're at risk of over-rotating on this one.

A callback is a call that is marked with Priority: helphelp (or
whatever) and the proxy makes some determination about call treatment
based on information it has.  This is likely caller identity == PSAP,
but it doesn't matter...let the operator choose a policy that both
complies with the laws of the land and with their customer's
preferences (i.e., their own business needs).

An emergency call is a call to urn:service:sos.  That call might be
marked as Priority: omgmyfacemyface, but the primary determinant for
how the call is treated is the callee, which is *by definition* a
PSAP.

Two cases, two sets of rules (one intentionally fuzzy, one crystal
clear).  Done.

--Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 19:42:15 -0400

Martin,

In an earlier reply to christer I agreed with you, that the mechanism 
for emergency calls works just fine without using Priority. That 
overloads a lot of things, but a big part of it is that the decision of 
who the call is *to* is delegated to the network more than it usually is.

> preferences (i.e., their own business needs).

It sounds like you are agreeing with me that a psap callback may not be 
"back" to a phone that made an emergency call. And maybe its not even 
"back" to a person who made an emergency call.

Its just a call that the psap operator wants to receive special 
treatment. There may be policies about when this can be used, but that 
is different from building limitations into the mechanism.

	Thanks,
	Paul