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

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Sep 2012 13:49:50 +0200

Hi,

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

Yes.

So, the question is still: for callback, do we define a new Priority value or not?

Regards,

Christer

---

From: John-Luc Bakker <[email-masked]>
Date: Tue, 4 Sep 2012 18:47:14 +0000

Christer,

It seems below an argument is made for either very many distinct Priority header field values, each invoking a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs), or just one Priority header field value, identifying the policy in place for "emergency call back". As I understand it, the requirements can be satisfied by having just one Priority header field value. The single value we have today that fits the bill is "emergency". 

Regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, September 03, 2012 6:50 AM
To: Martin Thomson; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

Hi,

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

Yes.

Regards,

Christer
_______________________________________________
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: "Rosen, Brian" <[email-masked]>
Date: Tue, 4 Sep 2012 15:09:48 -0400

I don't think that is the issue.

Some folks believe the definition of "emergency" is wider than "emergency call back" and thus a new value is needed to differentiate.  They would argue that we can't redefine "emergency" to "emergency call back".  I think the other side would say that there are other fields in the INVITE would allow that differentiation, such as the to/from.

I continue to not care much, but observe that new values are cheap.

Brian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Sep 2012 09:42:09 +0200

Hi,

Then, no matter whether people think a new value is really required or not, would people object to defining a new value?

This is really about making a choice and getting the work done :)

Regards,

Christer

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: 4. syyskuuta 2012 22:10
To: John-Luc Bakker
Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2012 10:57:40 -0400

> This is really about making a choice and getting the work done :)

Given all the discussion that has occurred about he pros and cons, I am 
willing to accept either using "emergency" or using a new value.

(If the decision is to go with a new value, I reserve the right to argue 
about what it is called. You only get one chance to get that right, and 
some values will be clearer than others. But at the end of the day I 
will go along with whatever the consensus brings.)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 Sep 2012 17:04:31 +0200

I still prefer a new value, as a new value is the easiest way of ensuring that there is no existing incompatible usage of an existing value for some other purpose.

I don't see compatibility the other way as an issue, as I am not aware of any existing marking for a PSAP callback.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: 05 September 2012 15:58
> To: Christer Holmberg
> Cc: Rosen, Brian; [email-masked]
> > Then, no matter whether people think a new value is really required or
> not, would people object to defining a new value?
> >
> > Some folks believe the definition of "emergency" is wider than
> "emergency call back" and thus a new value is needed to differentiate.
> They would argue that we can't redefine "emergency" to "emergency call
> back".  I think the other side would say that there are other fields in
> the INVITE would allow that differentiation, such as the to/from.
> >
> >> It seems below an argument is made for either very many distinct
> Priority header field values, each invoking a policy that both complies
> with the laws of the land and with their customer's preferences (i.e.,
> their own business needs), or just one Priority header field value,
> identifying the policy in place for "emergency call back". As I understand
> it, the requirements can be satisfied by having just one Priority header
> field value. The single value we have today that fits the bill is
> "emergency".
> >>
> >> Regards,
> >>
> >> 	JL
> >>
> >>> 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.
> >>>
> >> 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: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Sep 2012 11:13:35 -0400

How about "emergencyCallBack"?
On Sep 5, 2012, at 10:57 AM, Paul Kyzivat <[email-masked]> wrote:

> Given all the discussion that has occurred about he pros and cons, I am willing to accept either using "emergency" or using a new value.
> 
> (If the decision is to go with a new value, I reserve the right to argue about what it is called. You only get one chance to get that right, and some values will be clearer than others. But at the end of the day I will go along with whatever the consensus brings.)
> 
> 	Thanks,
> 	Paul
> 
>> Regards,
>> 
>> Christer
>> 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2012 11:48:47 -0400

> How about "emergencyCallBack"?

Hardly anything in sip uses mixed case this way. So from that 
perspective I would counter with "emergency-callback".

But a more significant issue is what semantics this is intended to 
convey. In particular, is a call with this attribute of necessity a 
*callback*? Is anything in the call path justified in refusing the 
request if there was no preceding call for which this is a callback?

E.g. if psap received an emergency call from phone-1, and it is 
necessary to reconnect to a different phone, or perhaps even a different 
person, in order to continue handling the emergency, then it may be hard 
to describe that as a "callback". Yet the PSAP may want to do it, and I 
suppose the mechanism should allow it. If so, then "emergency-callback" 
has the wrong connotation. This is really why I find "emergency" to be 
appropriate. If we must have a new term, how about: 
"expedited-emergency", "urgent-emergency", "emergency-override"?

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Sep 2012 13:28:18 -0400

I don't think we are trying to create a marking for an arbitrary call placed from a PSAP to someone in another network.  The marking is specifically for call backs, and not other purposes.

I think that it IS acceptable to refuse such calls if there was no call out.  For example, if the call is to some sort of Contact address which, due to some local requirements, was formatted in some way specifically known to the local system, it might refuse the call to the device if there was no preceding emergency call.  A call to a normal AoR may not be refused, but may not get any special treatment if the marking has no way of being authenticated.  All of that is up to the local system and any intermediaries.  I think Christer, and most of us discussing this, only intend it to be used for a call back.

I think there is no need to generalize, and emergency-callback is just fine.

Brian

On Sep 5, 2012, at 11:48 AM, Paul Kyzivat <[email-masked]> wrote:

> Hardly anything in sip uses mixed case this way. So from that perspective I would counter with "emergency-callback".
> 
> But a more significant issue is what semantics this is intended to convey. In particular, is a call with this attribute of necessity a *callback*? Is anything in the call path justified in refusing the request if there was no preceding call for which this is a callback?
> 
> E.g. if psap received an emergency call from phone-1, and it is necessary to reconnect to a different phone, or perhaps even a different person, in order to continue handling the emergency, then it may be hard to describe that as a "callback". Yet the PSAP may want to do it, and I suppose the mechanism should allow it. If so, then "emergency-callback" has the wrong connotation. This is really why I find "emergency" to be appropriate. If we must have a new term, how about: "expedited-emergency", "urgent-emergency", "emergency-override"?
> 
> 	Thanks,
> 	Paul
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Sep 2012 10:32:24 -0700

psap-callback ?

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 5 Sep 2012 17:37:23 +0000

I prefer emergency-callback, but in the end it is just a name....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, September 05, 2012 1:32 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

psap-callback ?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2012 13:05:36 +0200

Hi,

So, my suggestion would then be that me and Hannes update the callback draft, and define a new value.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, September 05, 2012 1:32 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator

psap-callback ?

On 5 September 2012 10:28, Rosen, Brian <[email-masked]> wrote:
>>>> (If the decision is to go with a new value, I reserve the right to 
>>>> argue about what it is called. You only get one chance to get that 
>>>> right, and some values will be clearer than others. But at the end 
>>>> of the day I will go along with whatever the consensus brings.)
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ---- 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: Fri, 07 Sep 2012 09:52:34 -0400

> So, my suggestion would then be that me and Hannes update the callback draft, and define a new value.

This means the draft becomes a revision to 3261. And since it's means 
there is more than one place that defined values for the Priority header 
field, it probably makes sense to establish an IANA registry for the 
values, initialized from 3261 and this draft.

We will have to discuss with the ADs whether this needs to be reviewed 
by sipcore.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2012 16:10:25 +0200

Hi,

> This means the draft becomes a revision to 3261. And since it's means there is more than one place that defined values for the Priority header field, it probably makes sense to establish an IANA registry for the values, initialized from 3261 and this draft.

I am not sure what you mean by revision. 3261 already allows new Priority header field values. AFAIK, a new value DOES require an RFC, though.

> We will have to discuss with the ADs whether this needs to be reviewed by sipcore.

Agree.

Regards,

Christer

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 7 Sep 2012 10:19:56 -0400

I don't think this is necessarily an update to 3261, which says:
   … The header field can
   have the values "non-urgent", "normal", "urgent", and "emergency",
   but additional values can be defined elsewhere

"Elsewhere" is not a defined term, so we get to decide what we want it to be.

I think a registry is nice to have, and since it would have a management policy, it would define what "elsewhere" means.  I personally don't think that means it updates 3261, but if you wanted to alert a reader that "elsewhere" includes an entry in a registry, I wouldn't mind calling it an update to 3261.  I don't think a registry is essential, and if adding a registry makes this a big deal instead of a little deal, then I'd forgo the registry.

I think we probably ought to have sipcore review it.

Brian

---

From: James Polk <[email-masked]>
Date: Fri, 07 Sep 2012 16:51:41 -0500

>psap-callback ?

this value is as concrete as any I've read or heard or suggested 
myself. It states exactly what's happening and cannot be 
misinterpreted - which is a very good thing.

I'll bow to Paul's investigation into what about this needs to be 
done wrt SIPCORE, given that there is no TOKEN defined for 
extensibility in this header (which would have made this rather easy).

James

> > I don't think we are trying to create a marking for an arbitrary 
> call placed from a PSAP to someone in another network.  The marking 
> is specifically for call backs, and not other purposes.
> >
> > I think that it IS acceptable to refuse such calls if there was 
> no call out.  For example, if the call is to some sort of Contact 
> address which, due to some local requirements, was formatted in 
> some way specifically known to the local system, it might refuse 
> the call to the device if there was no preceding emergency call.  A 
> call to a normal AoR may not be refused, but may not get any 
> special treatment if the marking has no way of being 
> authenticated.  All of that is up to the local system and any 
> intermediaries.  I think Christer, and most of us discussing this, 
> only intend it to be used for a call back.
> >
> >> But a more significant issue is what semantics this is intended 
> to convey. In particular, is a call with this attribute of 
> necessity a *callback*? Is anything in the call path justified in 
> refusing the request if there was no preceding call for which this 
> is a callback?
> >>
> necessary to reconnect to a different phone, or perhaps even a 
> different person, in order to continue handling the emergency, then 
> it may be hard to describe that as a "callback". Yet the PSAP may 
> want to do it, and I suppose the mechanism should allow it. If so, 
> then "emergency-callback" has the wrong connotation. This is really 
> why I find "emergency" to be appropriate. If we must have a new 
> term, how about: "expedited-emergency", "urgent-emergency", 
> "emergency-override"?
> >>
> >>       Thanks,
> >>       Paul
> >>
> >>>>> Then, no matter whether people think a new value is really 
> required or not, would people object to defining a new value?
> >>>>>
> >>>> Given all the discussion that has occurred about he pros and 
> cons, I am willing to accept either using "emergency" or using a new value.
> >>>>
> >>>> (If the decision is to go with a new value, I reserve the 
> right to argue about what it is called. You only get one chance to 
> get that right, and some values will be clearer than others. But at 
> the end of the day I will go along with whatever the consensus brings.)
> >>>>
> >>>>     Thanks,
> >>>>     Paul
> >>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> >>>>>
> >>>>> Some folks believe the definition of "emergency" is wider 
> than "emergency call back" and thus a new value is needed to 
> differentiate.  They would argue that we can't redefine "emergency" 
> to "emergency call back".  I think the other side would say that 
> there are other fields in the INVITE would allow that 
> differentiation, such as the to/from.
> >>>>>
> >>>>>> It seems below an argument is made for either very many 
> distinct Priority header field values, each invoking a policy that 
> both complies with the laws of the land and with their customer's 
> preferences (i.e., their own business needs), or just one Priority 
> header field value, identifying the policy in place for "emergency 
> call back". As I understand it, the requirements can be satisfied 
> by having just one Priority header field value. The single value we 
> have today that fits the bill is "emergency".
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>>   JL
> >>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>> 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: Mon, 10 Sep 2012 14:10:10 +0200

Hi,

>>psap-callback ?
>
> this value is as concrete as any I've read or heard or suggested myself. It states exactly what's happening and cannot be misinterpreted - which is a very good thing.
>
> I'll bow to Paul's investigation into what about this needs to be done wrt SIPCORE, given that there is no TOKEN defined for extensibility in this header (which would have made this rather easy).

Yes, there is :)

Priority       	 =  "Priority" HCOLON priority-value
priority-value  	=  "emergency" / "urgent" / "normal"
                   	/ "non-urgent" / other-priority
other-priority  	=  token

Regards,

Christer

> call placed from a PSAP to someone in another network.  The marking is 
> specifically for call backs, and not other purposes.
> >
> address which, due to some local requirements, was formatted in some 
> way specifically known to the local system, it might refuse the call 
> to the device if there was no preceding emergency call.  A call to a 
> normal AoR may not be refused, but may not get any special treatment 
> if the marking has no way of being authenticated.  All of that is up 
> to the local system and any intermediaries.  I think Christer, and 
> most of us discussing this, only intend it to be used for a call back.
> >
> to convey. In particular, is a call with this attribute of necessity a 
> different person, in order to continue handling the emergency, then it 
> may be hard to describe that as a "callback". Yet the PSAP may want to 
> do it, and I suppose the mechanism should allow it. If so, then 
> "emergency-callback" has the wrong connotation. This is really why I 
> find "emergency" to be appropriate. If we must have a new term, how 
> about: "expedited-emergency", "urgent-emergency", 
> "emergency-override"?
> >>
> >>       Thanks,
> >>       Paul
> >>
> right to argue about what it is called. You only get one chance to get 
> that right, and some values will be clearer than others. But at the 
> end of the day I will go along with whatever the consensus brings.)
> >>>>
> >>>>     Thanks,
> >>>>     Paul
> >>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> >>>>>
> to "emergency call back".  I think the other side would say that there 
> are other fields in the INVITE would allow that differentiation, such 
> as the to/from.
> >>>>>
> call back". As I understand it, the requirements can be satisfied by 
> having just one Priority header field value. The single value we have 
> today that fits the bill is "emergency".
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>>   JL
> >>>>>>
> >>>>>>> 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).
> >>>>>>>
> >>>>>> ---------------------------------------------------------------
> >>>>>> ------ This transmission (including any attachments) may 
> >>>>>> contain
> 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: James Polk <[email-masked]>
Date: Wed, 12 Sep 2012 16:01:44 -0500

>                         / "non-urgent" / other-priority

oops... nevermind