Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Nov 2011 11:51:01 +0100

Hi,

In Taipei, it was indicated that people would prefer another mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls.

A new Resource-Priority header field value, that PSAPs would insert in callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. in order to give special treatment.

(The requirement to reach the same UA device that made the emergency call can be solved with the existing GRUU mechanism, so nothing new is needed there).

So, I would like to know whether people are ok with a Resource-Priority approach?

Regards,

Christer

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 Nov 2011 12:57:02 +0200

Hi Christer, 

In earlier discussions I was told that the SIP Resource Priority concept
refers to a different type of resource and so I had proposed a new
header in the past. However, when looking at RFC 4412 it may be vague
enough to allow the RPH concept to be re-used for this purpose:

   SIP applications may involve at least five different resources that

   may become scarce and congested during emergencies.  These resources

   include gateway resources, circuit-switched network resources, IP

   network resources, receiving end-system resources, and SIP proxy

   resources.  IP network resources are beyond the scope of SIP

   signaling and are therefore not considered here.

Does his include "bypassing whitelists and other authorization policies
at proxies" and "ignoring user interface settings like 'silent mode'"? 

What do you think? 

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Christer Holmberg
Sent: Thursday, November 24, 2011 12:51 PM
To: ECRIT
Cc: 'Adam Roach'; Paul Kyzivat
Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of
eGRUU

Hi,

In Taipei, it was indicated that people would prefer another mechanism
than a new GRUU type for solving the issue of identifying PSAP callback
calls.

A new Resource-Priority header field value, that PSAPs would insert in
callback calls, was suggested. It would solve the requirement of
allowing network entities (and the UA) to identity the callback call,
e.g. in order to give special treatment.

(The requirement to reach the same UA device that made the emergency
call can be solved with the existing GRUU mechanism, so nothing new is
needed there).

So, I would like to know whether people are ok with a Resource-Priority
approach?

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Nov 2011 19:05:19 +0100

Can people indicate why they see a synergy with resource priority.

This header field is primarily used for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the message handling depends on it.

While there may possibly be a use for Resource-Priority on emergency callbacks, in order to give priority, I would suggest that to give it a purpose beyond that where priority itself is not needed, is not using that header for its prime purpose, and indeed detracts from the main usage.

Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, because different regulatory regimes have different sets of rules as to what namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming user will need to cross the same country twice (on the signalling path) for the callback call, because the callback will go via the home network.

So while I have no axes to grind on losing a GRUU dependency, I do think Resource-Priority is a poor fit.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 24 November 2011 10:51
To: ECRIT
Cc: 'Adam Roach'; Paul Kyzivat
Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU

Hi,

Regards,

Christer

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Nov 2011 13:21:08 -0500

I share the concern about this use of RPH. I see a few alternatives that might be worth discussing:

- The "Priority" SIP header, which already has an "emergency" value.

- Using an sos service URN in the From header field.

In all cases, the In-Reply-To field allows the caller to determine that the return call is indeed in response to a call made earlier, at least. If the caller UA knows that the call-ID was an emergency call, this provides reasonable assurance that the return call is from a PSAP (or other entity that received the original call). If the calling UA did not recognize the call as emergency, none of the marking mechanism are likely to make much difference in terms of handling in any event.

Henning

On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Nov 2011 13:35:21 -0500

One of the things the GRUU got you was a token that could be used for authorization.  It's not just that it's a call back.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Nov 2011 13:49:19 -0500

How would a GRUU authorize the caller as "this is a PSAP"?

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Nov 2011 14:01:11 -0500

The original call is set up as a emergency call.  In that call is a token that can be used as a call back authentication token.  It's not that it's a PSAP (although PSAPs may have credentials that prove they are PSAPs), it's that it's a return call from the original emergency call.  If it's handled within https, it's even somewhat secure.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Nov 2011 14:07:33 -0500

But that's roughly the same authorization (nonce) model you have for the In-Reply-To. You had said earlier that this works only for call-backs, but that seems to be true for both. (The https security properties are the same, either way.) This approach requires no special modification of anything.

Henning

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Nov 2011 14:23:11 -0500

I never understood the need for a special GRUU, but Christer thought it was important.

I'm not sure we need a marking.  If we do, some urn in FROM is fine.  Not sure I would use urn:service:sos, but if it was limited to the immediate return to the device that usually results from some sort of premature disconnect, then it makes sense.  A call back a few days later (which is likely to the AoR, not Contact) with a from of urn:service:sos makes little sense to me.

Brian

On Nov 28, 2011, at 2:05 PM, Paul Kyzivat wrote:

> On 11/29/11 2:35 AM, Brian Rosen wrote:
>> One of the things the GRUU got you was a token that could be used for
>> authorization. It's not just that it's a call back.
> 
> I don't understand how that would work.
> 
> In any case, I don't object to using a GRUU for callback. (That's what its for).  But I do object to inventing a new sort of GRUU, that needs to be widely understood, just for emergency calls. The mechanism is pretty heavy weight to add on for that.
> 
> IMO it should be sufficient to use a temp gruu. There can be lots of them, so the UAC can use a unique one for the emergency call, and remember to treat callbacks to that one specially. The fact that it is a gruu (the "gr" parameter) *should* be a cue that many disruptive services should be disabled along the signaling path - not because it is an emergency call, but because the call is intended to go to a specific endpoint. And if that isn't enough, callerprefs could also be used to request that automata be bypassed in favor of a human.
> 
> This could be coupled with other indicators, such as an sos urn in the from field.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>> 
>>> In all cases, the In-Reply-To field allows the caller to determine
>>> that the return call is indeed in response to a call made earlier, at
>>> least. If the caller UA knows that the call-ID was an emergency call,
>>> this provides reasonable assurance that the return call is from a PSAP
>>> (or other entity that received the original call). If the calling UA
>>> did not recognize the call as emergency, none of the marking mechanism
>>> are likely to make much difference in terms of handling in any event.
>>> 
>>> Henning
>>> 
>>>> This header field is primarily used for giving priority in the
>>>> network. To be used effectively, it needs to be processed first in
>>>> any message at all SIP entities, and the rest of the message handling
>>>> depends on it.
>>>> 
>>>> While there may possibly be a use for Resource-Priority on emergency
>>>> callbacks, in order to give priority, I would suggest that to give it
>>>> a purpose beyond that where priority itself is not needed, is not
>>>> using that header for its prime purpose, and indeed detracts from the
>>>> main usage.
>>>> 
>>>> Further, one thing that could well disappear at country boundaries is
>>>> the Resource-Priority header field, because different regulatory
>>>> regimes have different sets of rules as to what namespaces may be
>>>> used, and do not necessarily map one to another. Any 3GPP roaming
>>>> user will need to cross the same country twice (on the signalling
>>>> path) for the callback call, because the callback will go via the
>>>> home network.
>>>> 
>>>> ------------------------------------------------------------------------
>>>> 
>>>> *From:[email-masked] <mailto:[email-masked]>
>>>> [mailto:[email-masked]] *On Behalf Of *Christer Holmberg
>>>> *Sent:* 24 November 2011 10:51
>>>> *To:* ECRIT
>>>> *Cc:* 'Adam Roach'; Paul Kyzivat
>>>> *Subject:* [Ecrit] PSAP Callback indication: Resrouce-Priority
>>>> instead of eGRUU
>>>> 
>>>> Hi,
>>>> 
>>>> In Taipei, it was indicated that people would prefer another
>>>> mechanism than a new GRUU type for solving the issue of identifying
>>>> PSAP callback calls.
>>>> 
>>>> A new Resource-Priority header field value, that PSAPs would insert
>>>> in callback calls, was suggested. It would solve the requirement of
>>>> call can be solved with the existing GRUU mechanism, so nothing new
>>>> is needed there).
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 28 Nov 2011 14:19:11 -0500

Not sure that would work for IMS, but it's okay in general.  Anyplace where a parameter is allowed can be made to work if it is sent in the call and accepted in the call back.  

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 28 Nov 2011 19:58:40 +0000

If I recall correctly, the reasons given in the Taipei meeting for indicating a PSAP call-back is any "different" from a normal call to a normal GRUU or a normal AoR or URI target, were so that: 
	(1) the network prioritize the call-back with respect to allocating resources
	(2) the network bypass certain normal-call "treatments"
	(3) so that the reached UA could know to immediately answer the call. 

For (1): if that's not the very definition of the RPH header's purpose, I don't know what is.

For (2): we have never had a singular defined header or field in SIP which was intended for this purpose, afaik - basically there are many headers/fields/methods which in combination are used by proxy-ish devices to perform different "treatments".  In 3GPP, for example, I believe the filter-criteria can and do use almost any header field.  So really there's no field we can't use to accomplish this.

For (3): using a new RPH namespace value for "psap-callback" actually makes sense for this, since it's arguably asking the UA to make available its resources immediately, without waiting for user consent or to put another call on hold.

Having said all that, I'm not super-tied to using the RPH header either - I just think using a new special GRUU type is wrong, both at an architectural level and a practical "it-needs-to-work" level.  Even if the RPH field is lost or modified or ignored, for example, the call will likely succeed - that's a good property to have I would think. 

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Nov 2011 15:18:54 -0500

I see the issues as somewhat orthogonal. Thus, the use of GRUU or In-Reply-To could easily be combined with RPH.

Indeed, we've always distinguished Priority (meant to indicate the desired priority at the receiving end system) and Resource-Priority (meant to influence scheduling at intermediate nodes, such as gateways and proxies).

I agree that the fail-safe mode is desirable, in addition to making spoofing such calls at least modestly difficult. We do not want telemarketers to bypass call filters by slapping on an RPH.

I admit that I still don't see what's wrong with the following combination:

- In-Reply-To allows the UA to match the call to an earlier emergency call and thus prevents impersonation (weakly, but probably sufficiently to deal with the most likely threat). It can also be used to bypass end system call handling.

- RPH can be added if needed, but seems likely to have modest to no effect. Using it to bypass call handling by itself seems like a bad idea, for the reason noted above. If the user's proxy keeps track of outbound emergency calls, In-Reply-To works for that as well.

- "Priority: emergency" can be used as well, as an indicator for call handling, but obviously needs some validation.

We need to decide whether we require proxies to keep state for recent emergency calls; otherwise and in the absence of a PKI-like mechanism, it seems difficult to prevent call impersonation at the user's proxy.

There are other ways to solve this; in particular, Kumiko presented the ARID proposal at the last DISPATCH meeting on how a callee could validate caller properties. This requires more UA changes, but is stateless in the UA and works across devices.

Henning

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Nov 2011 21:48:52 +0100

I have no problem with using Resource-Priority for (1). However not many administrations appear to prioritise callbacks either in the network or in the network access. Whether that will change when they have a means to do so I do not known. It is when RPH is used for the other functions, particularly in the absence of a need for (1) that I have issues.

I'd add a (4) or possibly a (3A) to your list which is that the UA bypasses certain normal call treatments (such as removing call deflection from the user's soft menu or such like).

So for both (2) and (4) I would regard as the main uses, and RPH is not a good fit for those two.

I would contend that (3) is not a good use of RPH, as RPH works on areas of trust of the namespace, is the recipient UA in the namespace, and does it trust the sender? Surely this is the function of the Priority header field. Indeed RPH specifically does not "asking the UA to make available its resources immediately, without waiting for user consent or to put another call on hold"; rather it asks the recipient to place the message in a queue appropriate to the received namespace (and possibly priority) and handle that queue versus the normal call queue according to the rules of the namespace involved. As the namespace definitions (as in the RFCs) normally leave that level of detail to the implementors of the namespace in the closed net of implementing equipment, it is unlikely UA vendors will pick that information up.

Regards

Keith

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 28 November 2011 19:59
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; ECRIT; Adam Roach; Paul Kyzivat
> Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead
> of eGRUU
> 
> 
> If I recall correctly, the reasons given in the Taipei meeting for
> indicating a PSAP call-back is any "different" from a normal call to a
> normal GRUU or a normal AoR or URI target, were so that:
> For (2): we have never had a singular defined header or field in SIP which
> was intended for this purpose, afaik - basically there are many
> headers/fields/methods which in combination are used by proxy-ish devices
> to perform different "treatments".  In 3GPP, for example, I believe the
> filter-criteria can and do use almost any header field.  So really there's
> no field we can't use to accomplish this.
> 
> For (3): using a new RPH namespace value for "psap-callback" actually
> makes sense for this, since it's arguably asking the UA to make available
> its resources immediately, without waiting for user consent or to put
> another call on hold.
> 
> Having said all that, I'm not super-tied to using the RPH header either -
> I just think using a new special GRUU type is wrong, both at an
> architectural level and a practical "it-needs-to-work" level.  Even if the
> RPH field is lost or modified or ignored, for example, the call will
> likely succeed - that's a good property to have I would think.
> 
> -hadriel
> 
> 
> > This header field is primarily used for giving priority in the network.
> To be used effectively, it needs to be processed first in any message at
> all SIP entities, and the rest of the message handling depends on it.
> >
> callbacks, in order to give priority, I would suggest that to give it a
> purpose beyond that where priority itself is not needed, is not using that
> header for its prime purpose, and indeed detracts from the main usage.
> >
> the Resource-Priority header field, because different regulatory regimes
> have different sets of rules as to what namespaces may be used, and do not
> necessarily map one to another. Any 3GPP roaming user will need to cross
> the same country twice (on the signalling path) for the callback call,
> because the callback will go via the home network.
> >
> Of Christer Holmberg
> callback calls, was suggested. It would solve the requirement of allowing
> network entities (and the UA) to identity the callback call, e.g. in order
> to give special treatment.
> >

---

From: Andrew Allen <[email-masked]>
Date: Mon, 28 Nov 2011 21:57:12 +0000

With regard to 1)2)3) from Hariel

1) This is a new semantic for a GRUU but I don't think inconsistent with it. A GRUU is just a URI and there is no reason a service provider cannot prioritize handling of requests destined for certain URIs over other URIs. In fact they may do this already (for example when the R-URI contains the SOS URN).

2) Request's destined for GRUUs often would override call features (particularly those that would result in the request being redirected to a different recipient other than that identified by the GRUU). So this seems to me perfectly consistent with GRUU usage and properties.

3) Determining whether to answer or not answer a call was one of the primary reasons for being able to mint multiple but unique temporary GRUUs. So that the caller (or calling UA) can identify the source (or type of source) of the incoming request based on knowing the purpose of the outgoing request that provided the GRUU to the other party in the first place. This was the knowing when the car salesman is calling you back privacy issue with regard to GRUUs. So having a UA determine whether to accept a call based or not based on a particular GRUU being received in the R-URI seems totally appropriate to me.

I am sure we can come up with all kinds of new ways to indicate this but basing this on the GRUU mechanism provides most of the properties that we need, like temporary GRUUs, emergency GRUUs can be invalidated and new ones issued by the service provider to minimize the opportunity for abuse by other parties that might obtain them (if we define a new header or magic predefined token what prevents someone else using it to spoof an emergency call back?). Emergency GRUU also builds upon the existing mechanisms for GRUU allocation and routing which we have already defined. In any case the PSAP needs to use a GRUU in the R-URI to ensure that the original terminal that placed the emergency call is reached so why not make this GRUU also the means of identifying that this is an emergency call back? 

Not being in Taipei was there a problem identified with the emergency GRUU proposal?

Andrew 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hadriel Kaplan
> Sent: Monday, November 28, 2011 1:59 PM
> To: DRAGE, Keith (Keith)
> Cc: Adam Roach; ECRIT; Paul Kyzivat

---------------------------------------------------------------------
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: Tue, 29 Nov 2011 10:51:25 +0100

Hi,

First, some background on the new gruu type: I had made the assumption (which turned out to be false) that we have very little influense when it comes to PSAP behavior. So, using a new GRUU type, the UA would "provide" the identifier to the PSAP in the Contact header field of the emergency call from the UE, and we would then only have to assume that the PSAP uses that Contact when making the PSAP Callback.
An advantage of NOT using a new gruu type, but rather something generated by the PSAP itself, is of course that networks can identity PSAP Callbacks also towards UAs that don't support the new gruu type.

Second, regarding usage of In-Reply-To: while it may allow the UA to match the calls, it won't work for network entities - not even if the network entities are stateful, as the emergency call, and the associated PSAP Callback, might not traverse the same network entities. As Keith said, at least in a 3GPP roaming scenario, the PSAP Callback will traverse the home network.

In addition, In-Reply-To contains a Call-Id, and we all know what SBCs etc can do to those :)

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: 28. marraskuuta 2011 22:19
> To: Hadriel Kaplan
> Subject: Re: [Ecrit] PSAP Callback indication: 
> Resrouce-Priority instead of eGRUU
> 
> I see the issues as somewhat orthogonal. Thus, the use of 
> GRUU or In-Reply-To could easily be combined with RPH.
> 
> Indeed, we've always distinguished Priority (meant to 
> indicate the desired priority at the receiving end system) 
> and Resource-Priority (meant to influence scheduling at 
> intermediate nodes, such as gateways and proxies).
> 
> I agree that the fail-safe mode is desirable, in addition to 
> making spoofing such calls at least modestly difficult. We do 
> not want telemarketers to bypass call filters by slapping on an RPH.
> 
> - In-Reply-To allows the UA to match the call to an earlier 
> emergency call and thus prevents impersonation (weakly, but 
> probably sufficiently to deal with the most likely threat). 
> It can also be used to bypass end system call handling.
> 
> - RPH can be added if needed, but seems likely to have modest 
> to no effect. Using it to bypass call handling by itself 
> seems like a bad idea, for the reason noted above. If the 
> user's proxy keeps track of outbound emergency calls, 
> In-Reply-To works for that as well.
> 
> - "Priority: emergency" can be used as well, as an indicator 
> for call handling, but obviously needs some validation.
> 
> We need to decide whether we require proxies to keep state 
> for recent emergency calls; otherwise and in the absence of a 
> PKI-like mechanism, it seems difficult to prevent call 
> impersonation at the user's proxy.
> 
> There are other ways to solve this; in particular, Kumiko 
> presented the ARID proposal at the last DISPATCH meeting on 
> how a callee could validate caller properties. This requires 
> more UA changes, but is stateless in the UA and works across devices.
> 
> Henning
> 
> > If I recall correctly, the reasons given in the Taipei 
> meeting for indicating a PSAP call-back is any "different" 
> from a normal call to a normal GRUU or a normal AoR or URI 
> target, were so that: 
> > For (2): we have never had a singular defined header or 
> field in SIP which was intended for this purpose, afaik - 
> basically there are many headers/fields/methods which in 
> combination are used by proxy-ish devices to perform 
> different "treatments".  In 3GPP, for example, I believe the 
> filter-criteria can and do use almost any header field.  So 
> really there's no field we can't use to accomplish this.
> > 
> > For (3): using a new RPH namespace value for 
> "psap-callback" actually makes sense for this, since it's 
> arguably asking the UA to make available its resources 
> immediately, without waiting for user consent or to put 
> another call on hold.
> > 
> > Having said all that, I'm not super-tied to using the RPH 
> header either - I just think using a new special GRUU type is 
> wrong, both at an architectural level and a practical 
> "it-needs-to-work" level.  Even if the RPH field is lost or 
> modified or ignored, for example, the call will likely 
> succeed - that's a good property to have I would think. 
> > 
> > -hadriel
> > 
> > 
> >> This header field is primarily used for giving priority in 
> the network. To be used effectively, it needs to be processed 
> first in any message at all SIP entities, and the rest of the 
> message handling depends on it.
> >> 
> >> While there may possibly be a use for Resource-Priority on 
> emergency callbacks, in order to give priority, I would 
> suggest that to give it a purpose beyond that where priority 
> itself is not needed, is not using that header for its prime 
> purpose, and indeed detracts from the main usage.
> >> 
> >> Further, one thing that could well disappear at country 
> boundaries is the Resource-Priority header field, because 
> different regulatory regimes have different sets of rules as 
> to what namespaces may be used, and do not necessarily map 
> one to another. Any 3GPP roaming user will need to cross the 
> same country twice (on the signalling path) for the callback 
> call, because the callback will go via the home network.
> >> 
> >> So while I have no axes to grind on losing a GRUU 
> dependency, I do think Resource-Priority is a poor fit.
> >> 
> >> Keith
> >> 
> >> Subject: [Ecrit] PSAP Callback indication: 
> Resrouce-Priority instead 
> >> of eGRUU
> >> 
> >> 
> >> Hi,
> >> 
> >> In Taipei, it was indicated that people would prefer 
> another mechanism than a new GRUU type for solving the issue 
> of identifying PSAP callback calls.
> >> 
> >> A new Resource-Priority header field value, that PSAPs 
> would insert in callback calls, was suggested. It would solve 
> the requirement of allowing network entities (and the UA) to 
> identity the callback call, e.g. in order to give special treatment.
> >> 
> >> (The requirement to reach the same UA device that made the 
> emergency call can be solved with the existing GRUU 
> mechanism, so nothing new is needed there).
> >>

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 29 Nov 2011 12:16:56 -0500

With regard to the use of a new RPH namespace to trigger special handling 
or treatment in the network , I guess it depends on what you mean by 
"bypass call handling"
"bypass ... treatments"

Requirement 13 of  RFC 5390 (Requirements for Management of Overload in 
the  Session Initiation Protocol) says

REQ 13:  The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others.

This explicitly names  the RPH header as a way to identify calls needing 
"special treatment" in the face of SIP overload.  Not a complete "bypass", 
but definitely a "special treatment".

WRT "We do not want telemarketers to bypass call filters by slapping on an 
RPH." This is true of any use of any RPH namespace.  Use of RPH must 
always be combined with appropriate security/authentication/authorization 
measures to ensure that unauthorized entities can not "slap on an RPH".

I agree that, in principle, "Priority" rather than "Resource Priority" is 
the appropriate way to inform the destination  that special treatment at 
the destination is requested.  However anyone can "slap on a Priority 
header", as there is no associated security/authentication/authorization .

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   Henning Schulzrinne <[email-masked]>
To:     Hadriel Kaplan <[email-masked]>
Cc:     Adam Roach <[email-masked]>, ECRIT <[email-masked]>, Paul 
Kyzivat <[email-masked]>
Date:   11/28/2011 03:19 PM
Subject:        Re: [Ecrit] PSAP Callback indication: Resrouce-Priority 
instead of      eGRUU
Sent by:        [email-masked]

I see the issues as somewhat orthogonal. Thus, the use of GRUU or 
In-Reply-To could easily be combined with RPH.

Indeed, we've always distinguished Priority (meant to indicate the desired 
priority at the receiving end system) and Resource-Priority (meant to 
influence scheduling at intermediate nodes, such as gateways and proxies).

I agree that the fail-safe mode is desirable, in addition to making 
spoofing such calls at least modestly difficult. We do not want 
telemarketers to bypass call filters by slapping on an RPH.

I admit that I still don't see what's wrong with the following 
combination:

- In-Reply-To allows the UA to match the call to an earlier emergency call 
and thus prevents impersonation (weakly, but probably sufficiently to deal 
with the most likely threat). It can also be used to bypass end system 
call handling.

- RPH can be added if needed, but seems likely to have modest to no 
effect. Using it to bypass call handling by itself seems like a bad idea, 
for the reason noted above. If the user's proxy keeps track of outbound 
emergency calls, In-Reply-To works for that as well.

- "Priority: emergency" can be used as well, as an indicator for call 
handling, but obviously needs some validation.

We need to decide whether we require proxies to keep state for recent 
emergency calls; otherwise and in the absence of a PKI-like mechanism, it 
seems difficult to prevent call impersonation at the user's proxy.

There are other ways to solve this; in particular, Kumiko presented the 
ARID proposal at the last DISPATCH meeting on how a callee could validate 
caller properties. This requires more UA changes, but is stateless in the 
UA and works across devices.

Henning

indicating a PSAP call-back is any "different" from a normal call to a 
normal GRUU or a normal AoR or URI target, were so that: 
> For (2): we have never had a singular defined header or field in SIP 
which was intended for this purpose, afaik - basically there are many 
> 
> Having said all that, I'm not super-tied to using the RPH header either 
- I just think using a new special GRUU type is wrong, both at an 
architectural level and a practical "it-needs-to-work" level.  Even if the 
RPH field is lost or modified or ignored, for example, the call will 
likely succeed - that's a good property to have I would think. 
Of Christer Holmberg
eGRUU
approach?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Nov 2011 12:41:37 -0500

Janet,

I think we all agree that no label by itself (whether some special From value, a Priority header or RPH) is sufficient to prevent abuse. It would only be useful in conjunction with another mechanism that allows caller-trusted parties, including the UA, to determine that the call is indeed in response to an earlier emergency call, or, alternatively, that only such calls can reach a special address, such as a GRUU. The logic would be something like

if (call claims to be an emergency-callback)
   check if earlier call was indeed an emergency call

Henning

On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote:

> With regard to the use of a new RPH namespace to trigger special handling or treatment in the network , I guess it depends on what you mean by 
> "bypass call handling" 
> "bypass ... treatments" 
> 
> Requirement 13 of  RFC 5390 (Requirements for Management of Overload in the  Session Initiation Protocol) says 
> 
> This explicitly names  the RPH header as a way to identify calls needing "special treatment" in the face of SIP overload.  Not a complete "bypass", but definitely a "special treatment". 
> 
> WRT "We do not want telemarketers to bypass call filters by slapping on an RPH." This is true of any use of any RPH namespace.  Use of RPH must always be combined with appropriate security/authentication/authorization  measures to ensure that unauthorized entities can not "slap on an RPH". 
> 
> I agree that, in principle, "Priority" rather than "Resource Priority" is the appropriate way to inform the destination  that special treatment at the destination is requested.  However anyone can "slap on a Priority header", as there is no associated security/authentication/authorization . 
> 
> Janet 
> 
> 
> This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 
> 
> 
> 
> Cc:        Adam Roach <[email-masked]>, ECRIT <[email-masked]>, Paul Kyzivat <[email-masked]> 
> Subject:        Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead        of        eGRUU