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

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Nov 2011 20:44:12 +0100

Hi,

I agree that, whatever protocol element we use, the element itself is not enough to prevent abuse. If the request comes from a non-trusted entity, there needs to be a way to verify it.

However, different networks might have different ways of doing that, and I don't think we need to standardize a mechanism before moving forward with specifying the identifier itself. We do need, however, have strong wording about the fact that there must be A way to verify that the call comes from a PSAP.

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

That does not work for all network entities, as they might not be aware of the previous emergency call. But, once the identifier has been verified, other entities within the trust domain can use that verification.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Henning Schulzrinne [[email-masked]]
Sent: Tuesday, November 29, 2011 7:41 PM
To: Janet P Gunn
Cc: Paul Kyzivat; Adam Roach; ECRIT; [email-masked]
Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority        instead of      eGRUU

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

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

On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote:

>
> 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
>
>
> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:
>
>> 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]> [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 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
>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit
>

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 29 Nov 2011 20:26:23 -0600

Christer

The fundamental requirement is to provide an indication to SIP 
request receivers (i.e., each SIP server along the way until you 
reach the ultimate destination UAS - which is the original UAC that 
placed the emergency call) to give that SIP request - which is an 
emergency callback 3 transaction - extra attention if needed to make 
sure it goes through, right?

If this is the general problem, then IMO

         Priority: Emergency

does not accomplish this goal, as the Priority header value is for 
users of UAs, not for intermediaries to take into account in any way.

Further, since there must be a new Call-ID value, there is no way to 
tie this back to the initial emergency call.

Additionally, the original UAC, may have called for emergency twice, 
and gotten connected to two different PSAPs. A generic "this is a 911 
callback" indication is insufficient, as I believe this needs to be 
tied somehow to which 911 call was placed. Given that the 911 
callback path could traverse a different set of SIP servers back to 
the original caller, SIP servers would have to blindly give 
preferential treatment to any SIP request that contains this "this is 
a 911 callback" - which is begging for misuse and other problems.

What sounds like the best proposal to me, and I'm not sure who 
mentioned it (Brian?), is for the original 911 caller to insert a 
token that is received during the callback INVITE (along with the sos 
URN somewhere in the INVITE). Maybe the token is something encrypted 
with the public key that identifies the PSAP from the 200 OK in the 
original transaction. If that same identifier comes back in the 
callback INVITE, the UAS knows who it is talking to. That doesn't 
solve for what has to happen within the SIP servers or in the network 
to ensure this SIP request gets preferential treatment, but most here 
already believe this is going to take a couple of pieces to get to 
where we want to go.

James

At 01:44 PM 11/29/2011, Christer Holmberg wrote:

>Hi,
>
>I agree that, whatever protocol element we use, the element itself 
>is not enough to prevent abuse. If the request comes from a 
>non-trusted entity, there needs to be a way to verify it.
>
>However, different networks might have different ways of doing that, 
>and I don't think we need to standardize a mechanism before moving 
>forward with specifying the identifier itself. We do need, however, 
>have strong wording about the fact that there must be A way to 
>verify that the call comes from a PSAP.
>
>That does not work for all network entities, as they might not be 
>aware of the previous emergency call. But, once the identifier has 
>been verified, other entities within the trust domain can use that 
>verification.
>
>Regards,
>
>Christer
>
>
>From: [email-masked] [[email-masked]] On Behalf Of 
>Henning Schulzrinne [[email-masked]]
>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
>
>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"
>
>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]<mailto:[email-masked]>>
>To:        Hadriel Kaplan 
><[email-masked]<mailto:[email-masked]>>
>Cc:        Adam Roach <[email-masked]<mailto:[email-masked]>>, 
>ECRIT <[email-masked]<mailto:[email-masked]>>, Paul Kyzivat 
><[email-masked]<mailto:[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.
>
>- 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
> >>
> >> From: [email-masked]<mailto:[email-masked]> 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> >> 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).
> >>
>[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 11:22:03 +0100

Hi James,

> The fundamental requirement is to provide an indication to
> SIP request receivers (i.e., each SIP server along the way
> until you reach the ultimate destination UAS - which is the
> original UAC that placed the emergency call) to give that SIP
> request - which is an emergency callback 3 transaction -
> extra attention if needed to make sure it goes through, right?

Yes.

(There is also a requirement to be able to reach the same UA that made the emergency call. But, gruu provides that, so we don't need to specify anything new.)

> does not accomplish this goal, as the Priority header value
> is for users of UAs, not for intermediaries to take into
> account in any way.

Please remember that lots of the actions taken by the intermediaries are on behalf of the user/UA. For example, an intermediarie would normally trigger a specific service for a specific user/UA, but it would not do so in the case of a PSAP Callback towards that user/UA.

> Further, since there must be a new Call-ID value, there is no
> way to tie this back to the initial emergency call.

I think Henning's idea was to use the In-Reply-To header field, which would contain the Call-Id of the associated emergency call.

But, as I said, it would not work with SBCs, and it would not work with intermediaries that weren't involved in the emergency call.

> Additionally, the original UAC, may have called for emergency
> twice, and gotten connected to two different PSAPs. A generic
> "this is a 911 callback" indication is insufficient, as I
> believe this needs to be tied somehow to which 911 call was
> placed. Given that the 911 callback path could traverse a
> different set of SIP servers back to the original caller, SIP
> servers would have to blindly give preferential treatment to
> any SIP request that contains this "this is a 911 callback" -
> which is begging for misuse and other problems.

There would need to be a way for networks, when receiving a "this is a 911 callback" request from a non-trusted network, to be able to verify that the call comes from a PSAP.

But, again, at least in a 3GPP roaming scenario the home network might not have a clue about the associated emergency call.

> What sounds like the best proposal to me, and I'm not sure
> who mentioned it (Brian?), is for the original 911 caller to
> insert a token that is received during the callback INVITE
> (along with the sos URN somewhere in the INVITE). Maybe the
> token is something encrypted with the public key that
> identifies the PSAP from the 200 OK in the original
> transaction. If that same identifier comes back in the
> callback INVITE, the UAS knows who it is talking to.

The original idea with the emergency gruu was that the home registrar provides such token to the UAS. The home registrar could then use that token to identify the PSAP Callback.

One problem with that was that there might also be other entities that need to identify the PSAP Callback, and for that reason the draft suggests a "static" token value ("psapcb"). But, with a static value you of course have the fraud/misuse issue.

Regards,

Christer

> That doesn't solve for what has to happen within the SIP servers
> or in the network to ensure this SIP request gets
> preferential treatment, but most here already believe this is
> going to take a couple of pieces to get to where we want to go.

> >I agree that, whatever protocol element we use, the element
> itself is
> >not enough to prevent abuse. If the request comes from a non-trusted
> >entity, there needs to be a way to verify it.
> >
> >have strong wording about the fact that there must be A way
> to verify
> >that the call comes from a PSAP.
> >
> >That does not work for all network entities, as they might
> not be aware
> >of the previous emergency call. But, once the identifier has been
> >verified, other entities within the trust domain can use that
> >verification.
> >
> >Regards,
> >
> >Christer
> >
> >
> >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
> >
> >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
> >
> >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
> 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
> >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.
> >
> >
> >
> >(meant to influence scheduling at intermediate nodes, such
> as gateways
> >and proxies).
> >
> 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.
> >
> >- "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
> > 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:
> > 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.
> > >
> > either - I just think using a new special GRUU type is
> wrong, both at
> > an architectural level and a practical "it-needs-to-work"
> > example, the call will likely succeed - that's a good
> property to have
> > I would think.
> > >
> > > -hadriel
> > >
> > >
> > 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.
> > >>
> > 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.
> > >>
> namespaces
> > may be used, and do not necessarily map one to another.
> > the signalling path) for the callback call, because the
> callback will
> > go via the home network.
> > >>
> > requirement of allowing network entities (and the UA) to
> identity the
> > callback call, e.g. in order to give special treatment.
> > >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Nov 2011 23:08:37 +0800

ISTM that a callback to the Contact address of a prior call should 
typically bypass many treatments, regardless of who it is from. In 
particular, it ought to go to the specific device identified by the 
contact address, not to some other device, VM server, etc.

Perhaps that isn't what happens with IMS right now, but then maybe that 
ought to be re-thought.

If that was normal behavior, then what else would be required for 
callbacks by a psap? There may need to be special treatment by the UA 
itself, but that can be handled by using a unique temp gruu for the 
emergency call and remembering it in order to detect emergency callbacks 
in the UA.

What am I missing? What sort of disruptive services do you expect will 
be applied to calls to a gruu?

	Thanks,
	Paul

On 11/30/11 6:22 PM, Christer Holmberg wrote:
>>> Cc:        Adam Roach<[email-masked]<mailto:[email-masked]>>,
>>> ECRIT<[email-masked]<mailto:[email-masked]>>, Paul Kyzivat

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 20:22:11 +0100

Hi,

> typically bypass many treatments, regardless of who it is from.
>
> In particular, it ought to go to the specific device identified by the
> callbacks by a psap?
> There may need to be special treatment by the UA

I don't think one can assume that any type of call, non-PSAP-callbacks and PSAP-callbacks, will be given the same special treatment by the network, just because they are addressed using a Contact.

And, it is not only about routing to another device, but also other services that normally would be applied.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 03:50:59 +0800

> And, it is not only about routing to another device, but also other services that normally would be applied.

Rather than talk generically about "services", can we get tangible about 
what sorts of things the network might do that would be detrimental to a 
psap callback?

AFAIK about the only thing that the network can do involves routing to 
some device other than the one addressed by the r-uri. E.g.
- route to a VM server or message server that responds in some way.
- forward to some other configured address

IMO neither of those are appropriate if the URI is a gruu for a specific 
device and that device is reachable. They would be appropriate even for 
a psap callback if the device is not reachable.

The other thing it could do is blacklist the call - returning an error 
response. That would be bad, and we should be considering how to avoid 
that. But perhaps it is the only thing to worry about.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 20:57:56 +0100

Hi,

> a psap callback if the device is not reachable.

Again, it's not only about routing to a specific device.

Before the request even reaches the device, it might e.g. be routed to different application servers in the network, triggering different kind of non-routing related services. A "normal" gruu addressed call could still be routed to such application servers, while a PSAP callback wouldn't.

Regards,

Christer

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 04:06:03 +0800

> Before the request even reaches the device, it might e.g. be routed to different application servers in the network, triggering different kind of non-routing related services. A "normal" gruu addre…

Without some tangible examples, what you say is just so much 
"mumble,mumble" to me.

Either it is routed to some alternative device that terminates the call 
instead of the intended device, or else it is routed through some device 
that simply acts as an intermediary, still allowing the call to reach 
the intended device, or else it fails the call.

Anything that acts as an intermediary, still allowing the call to reach 
the intended destination, is probably benign. (Do you have a 
counter-example?)

Anything that routes to someplace other than the intended device is of 
dubious appropriateness when the r-uri is a GRUU. Again I'd be 
interested to hear some examples.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 30 Nov 2011 15:00:32 -0600

At 01:50 PM 11/30/2011, Paul Kyzivat wrote:
>>I don't think one can assume that any type of call, 
>>non-PSAP-callbacks and PSAP-callbacks, will be given the same 
>>special treatment by the network, just because they are addressed 
>>using a Contact.
>>
>Rather than talk generically about "services", can we get tangible 
>about what sorts of things the network might do that would be 
>detrimental to a psap callback?
>
>AFAIK about the only thing that the network can do involves routing 
>to some device other than the one addressed by the r-uri. E.g.
>IMO neither of those are appropriate if the URI is a gruu for a 
>specific device and that device is reachable. They would be 
>appropriate even for a psap callback if the device is not reachable.

however ISTM that if any intermediary is in a congestion state, this 
callback would suffer like all other  INVITEs (especially if SOC 
mechanisms are implemented), which - I don't believe - we or Christer 
wants to have happen.  In that case, RP is the defined SIP mechanism 
to give special treatment to the request, but it can't be the only 
aspect that's different about this INVITE. I think you still need a 
GRUU (at least).

James

>The other thing it could do is blacklist the call - returning an 
>error response. That would be bad, and we should be considering how 
>to avoid that. But perhaps it is the only thing to worry about.
>
>         Thanks,
>         Paul
>
>>Regards,
>>
>>Christer
>>
>>
>>>(There is also a requirement to be able to reach the same UA that 
>>>made the emergency call. But, gruu provides that, so we don't need 
>>>to specify anything new.)
>>>
>>>
>>>Please remember that lots of the actions taken by the 
>>>intermediaries are on behalf of the user/UA. For example, an 
>>>intermediarie would normally trigger a specific service for a 
>>>specific user/UA, but it would not do so in the case of a PSAP 
>>>Callback towards that user/UA.
>>>
>>>
>>>
>>>I think Henning's idea was to use the In-Reply-To header field, 
>>>which would contain the Call-Id of the associated emergency call.
>>>
>>>But, as I said, it would not work with SBCs, and it would not work 
>>>with intermediaries that weren't involved in the emergency call.
>>>
>>>
>>>There would need to be a way for networks, when receiving a "this 
>>>is a 911 callback" request from a non-trusted network, to be able 
>>>to verify that the call comes from a PSAP.
>>>
>>>But, again, at least in a 3GPP roaming scenario the home network 
>>>might not have a clue about the associated emergency call.
>>>
>>>
>>>The original idea with the emergency gruu was that the home 
>>>registrar provides such token to the UAS. The home registrar could 
>>>then use that token to identify the PSAP Callback.
>>>
>>>One problem with that was that there might also be other entities 
>>>that need to identify the PSAP Callback, and for that reason the 
>>>draft suggests a "static" token value ("psapcb"). But, with a 
>>>static value you of course have the fraud/misuse issue.
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 16:08:15 -0500

Paul,

"call barring" is a standard GSM service.  You can invoke it yourself with a "star code" or "hash code".  It's also possible to bar incoming calls only when roaming.  Similarly there are various flavors of call diversion (aka call forwarding) that can be set similarly.  This is what I meant.  Services the user invokes or to which he is subscribed, that have the effect of preventing delivery of a call.

tim

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2011 2:52 PM
> To: Dwight, Timothy M (Tim)
> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote:
> > Paul,
> >
> > I assume this "mumble mumble" refers to features in the 
> service provider network that might otherwise prevent the 
> callback from being delivered.  The subscriber might have 
> incoming calls barred for example.
> 
> Do you mean that the provider has barred calls because the 
> bill has not 
> been paid? I wouldn't consider this a "service" to the user of the 
> phone, but its a reality to deal with.
> 
> I guess that is a significant issue in the case where 
> outgoing emergency 
> calls are allowed.
> 
> This needs to be mentioned on the list.
> 	
> 	Thanks,
> 	Paul
> 
> 
> 
> > tim
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >> On Behalf Of Paul Kyzivat
> >> Sent: Wednesday, November 30, 2011 2:06 PM
> >> To: Christer Holmberg
> >> Cc: Adam Roach; ECRIT
> >> special treatment by the network, just because they are
> >> addressed using a Contact.
> >>>>>
> >>>>> And, it is not only about routing to another device, but
> >> also other services that normally would be applied.
> >>>>
> >>> Before the request even reaches the device, it might e.g.
> >> be routed to different application servers in the network,
> >> triggering different kind of non-routing related services. A
> >> "normal" gruu addressed call could still be routed to such
> >> application servers, while a PSAP callback wouldn't.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 05:29:49 +0800

> "call barring" is a standard GSM service.  You can invoke it yourself with a "star code" or "hash code".  It's also possible to bar incoming calls only when roaming.  Similarly there are various fl…

OK. These examples are much more helpful.
So it seems you are looking for another attribute that can be input to a 
policy engine that makes such decisions.

So, on one hand its desired to indicate that the caller wants this call 
to receive special treatment, and then there is the issue of determining 
if the caller is entitled to ask for such treatment.

ISTM that Priority:emergency should be sufficient as an indicator that 
the treatment is required. Its been stated that this is intended for use 
by the UAS. But the kinds of services we are discussing bypassing are in 
general provided on behalf of the UAS, so I think it still applies.

The Resource-Priority header probably also has a role here in cases 
where there are resource constraints in the network.

Deciding if the caller is permitted to request this then becomes the 
hard part.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 05:33:08 +0800

On 12/1/11 5:00 AM, James M. Polk wrote:
>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same special
>>> treatment by the network, just because they are addressed using a
>>> Contact.
>>>
> wants to have happen. In that case, RP is the defined SIP mechanism to
> give special treatment to the request, but it can't be the only aspect
> that's different about this INVITE.

I agree.

> I think you still need a GRUU (at
> least).

Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient to 
bypass call barring policies. If something else is needed for that then 
gruu may be irrelevant.

	Thanks,
	Paul

>>>> Please remember that lots of the actions taken by the intermediaries
>>>> are on behalf of the user/UA. For example, an intermediarie would
>>>> normally trigger a specific service for a specific user/UA, but it
>>>> would not do so in the case of a PSAP Callback towards that user/UA.
>>>>
>>>>
>>>>
>>>> There would need to be a way for networks, when receiving a "this is
>>>> a 911 callback" request from a non-trusted network, to be able to
>>>> draft suggests a "static" token value ("psapcb"). But, with a static
>>>> value you of course have the fraud/misuse issue.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 22:40:23 +0100

Hi, 

>> "call barring" is a standard GSM service.  You can invoke it yourself with a "star code" or "hash code". 
>> It's also possible to bar incoming calls only when roaming.  Similarly there are various flavors of call 
>> diversion (aka call forwarding) that can be set similarly.  This is what I meant.  Services the user 
>> invokes or to which he is subscribed, that have the effect of preventing delivery of a call.
>

Yes, this is a good example of where the service logic would be different.

But, in general, the idea is to not forward requests to application servers at all (even if the call would eventually still reach the correct device), e.g. due to the the risk of congestion etc (as indicated by James).

>> So it seems you are looking for another attribute that can be input to a policy engine that makes such decisions.
>
> So, on one hand its desired to indicate that the caller wants this call to receive special treatment, and then there is the issue of determining if the caller is entitled to ask for such treatment.

Correct.

> ISTM that Priority:emergency should be sufficient as an indicator that the treatment is required. Its been stated that this is intended for use by the UAS. But the kinds of services we are discussing 
> bypassing are in general provided on behalf of the UAS, so I think it still applies.

Agree (I earlier indicated the same).

> The Resource-Priority header probably also has a role here in cases where there are resource constraints in the network.
>
> Deciding if the caller is permitted to request this then becomes the hard part.

Yes. There needs to be a way for the network, when it receives a request claiming to be a PSAP Callback, to determine that the call comes from a PSAP. There might be different ways of doing that, depending on networks, environments, operator agreements etc.

Regards,

Christer

>> service provider network that might otherwise prevent the callback 
>> from being delivered.  The subscriber might have incoming calls 
>> barred for example.
>>
>> Do you mean that the provider has barred calls because the bill has 
>> not been paid? I wouldn't consider this a "service" to the user of 
>> the phone, but its a reality to deal with.
>>
>> I guess that is a significant issue in the case where outgoing 
>> emergency calls are allowed.
>>
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Paul Kyzivat
>>>>>>>> There may need to be special treatment by the UA itself, but 
>>>>>>>> that can be handled by using a unique temp
>>>> gruu for the
>>>> Either it is routed to some alternative device that terminates the 
>>>> call instead of the intended device, or else it is routed through 
>>>> some device that simply acts as an intermediary, still allowing the
>> call to reach
>>>> Anything that acts as an intermediary, still allowing the call to 
>>>> reach the intended destination, is probably benign. (Do you have a
>>>> counter-example?)
>>>>
>>>> Anything that routes to someplace other than the intended device is 
>>>> of dubious appropriateness when the r-uri is a GRUU. Again I'd be

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 22:43:30 +0100

Hi,

>> I think you still need a GRUU (at least).
>
> Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient to bypass call barring policies. If something else is needed for that then gruu may be irrelevant.

The proposal was that the emergency gruu would contain a "psapcb" token, which would have been used as an indicator for bypassing policies etc.

(But, yes, the verification of the sender still applies also to the egruu)

Regards,

Christer

>>>>> reach the ultimate destination UAS - which is the original UAC
>>>>> that placed the emergency call) to give that SIP request - which
>>>>> is an emergency callback 3 transaction - extra attention if needed
>>>>> to make sure it goes through, right?
>>>>
>>>> Yes.
>>>>
>>>> specific user/UA, but it would not do so in the case of a PSAP Callback towards that user/UA.
>>>>
>>>>
>>>>
>>>>> Further, since there must be a new Call-ID value, there is no way
>>>>> to tie this back to the initial emergency call.
>>>>
>>>>> "this is a 911 callback" indication is insufficient, as I believe
>>>>> this needs to be tied somehow to which 911 call was placed. Given
>>>>> that the 911 callback path could traverse a different set of SIP
>>>>> servers back to the original caller, SIP servers would have to
>>>>> blindly give preferential treatment to any SIP request that
>>>>> contains this "this is a 911 callback" - which is begging for
>>>>> misuse and other problems.
>>>>
>>>>> token that is received during the callback INVITE (along with the
>>>>> sos URN somewhere in the INVITE). Maybe the token is something
>>>>> encrypted with the public key that identifies the PSAP from the
>>>>> 200 OK in the original transaction. If that same identifier comes
>>>>> back in the callback INVITE, the UAS knows who it is talking to.
>>>>
>>>>> or in the network to ensure this SIP request gets preferential
>>>>> treatment, but most here already believe this is going to take a
>>>>> couple of pieces to get to where we want to go.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> James
>>>>>
>>>>>> not enough to prevent abuse. If the request comes from a
>>>>>> However, different networks might have different ways of doing
>>>>>> that, and I don't think we need to standardize a mechanism before
>>>>>> moving forward with specifying the identifier itself. We do need,
>>>>>> however, have strong wording about the fact that there must be A
>>>>>> way
>>>>> to verify
>>>>>>> if (call claims to be an emergency-callback) check if earlier
>>>>>>> call was indeed an emergency call
>>>>>>
>>>>>> From: [email-masked] [[email-masked]] On Behalf
>>>>>> Of Henning Schulzrinne [[email-masked]]
>>>>>> 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
>>>>>> if (call claims to be an emergency-callback) check if earlier
>>>>>> call was indeed an emergency call
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>> 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
>>>>>> Subject: Re: [Ecrit] PSAP Callback indication:
>>>>>> Resrouce-Priority instead of eGRUU Sent by:
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>> 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.
>>>>>>
>>>>>> - 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.
>>>>>>
>>>>>> devices to perform different "treatments". In 3GPP, for example,
>>>>>> I believe the filter-criteria can and do use almost any
>>>>> header field.
>>>>>> 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.
>>>>>>>
>>>>>> is not using that header for its prime purpose, and indeed
>>>>>> boundaries is the Resource-Priority header field, because
>>>>>> different regulatory regimes have different sets of rules as to
>>>>>> what
>>>>> namespaces
>>>>>> 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.
>>>>>>>>
>>>>>> mechanism than a new GRUU type for solving the issue of
>>>>>> identifying PSAP callback calls.
>>>>>>>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 16:55:12 -0500

Paul,

Does there need also to be some "time limit"?  ISTM that after some [relatively short] period of time, a call from a PSAP is no longer a "call back" and needn't be prioritized.  

tim

> Sent: Wednesday, November 30, 2011 3:30 PM
> Cc: [email-masked]
> Resrouce-Priority instead of eGRUU
> 
> > "call barring" is a standard GSM service.  You can invoke 
> it yourself with a "star code" or "hash code".  It's also 
> possible to bar incoming calls only when roaming.  Similarly 
> there are various flavors of call diversion (aka call 
> forwarding) that can be set similarly.  This is what I meant. 
>  Services the user invokes or to which he is subscribed, that 
> have the effect of preventing delivery of a call.
> 
> >> Resrouce-Priority instead of eGRUU
> >>
> >>>> Resrouce-Priority instead of eGRUU
> >>>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 17:04:34 -0500

Christer,

It seems a little dangerous to say that a PSAP callback would bypass all application servers.  Sometimes network routing functions are implemented in devices that architecturally (because of how they attach to the network) are considered application servers.  Consider the 3GPP VCC-AS for example...

Would inclusion of RPH sufficiently address potential server congestion?

tim

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2011 3:40 PM
> To: 'Paul Kyzivat'; Dwight, Timothy M (Tim)
> Cc: [email-masked]
> Subject: RE: [Ecrit] PSAP Callback indication: 
> it yourself with a "star code" or "hash code". 
> >> It's also possible to bar incoming calls only when 
> roaming.  Similarly there are various flavors of call 
> But, in general, the idea is to not forward requests to 
> application servers at all (even if the call would eventually 
> still reach the correct device), e.g. due to the the risk of 
> congestion etc (as indicated by James).
> 
> >> So it seems you are looking for another attribute that can 
> be input to a policy engine that makes such decisions.
> >
> > So, on one hand its desired to indicate that the caller 
> wants this call to receive special treatment, and then there 
> is the issue of determining if the caller is entitled to ask 
> for such treatment.
> 
> Correct.
> 
> > ISTM that Priority:emergency should be sufficient as an 
> indicator that the treatment is required. Its been stated 
> that this is intended for use by the UAS. But the kinds of 
> services we are discussing 
> > The Resource-Priority header probably also has a role here 
> in cases where there are resource constraints in the network.
> >
> Yes. There needs to be a way for the network, when it 
> receives a request claiming to be a PSAP Callback, to 
> determine that the call comes from a PSAP. There might be 
> different ways of doing that, depending on networks, 
> environments, operator agreements etc.
> 
> Regards,
> 
> Christer
> 
> 
> bill has

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 23:04:50 +0100

Hi,

I'm not Paul, but I will reply anyway :)

I will double check, but I don think that there is any time limit (at least not a "relatively short" one) for a call to be considered and treated as a callback. The network entities that makes the prioritization may not even know when the associtaed emergency call was made (so, if there were some time limit I think the callback would need to contain timing information).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: 30. marraskuuta 2011 23:55
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU

Paul,

tim

> it yourself with a "star code" or "hash code".  It's also possible to 
> bar incoming calls only when roaming.  Similarly there are various 
> flavors of call diversion (aka call
>  Services the user invokes or to which he is subscribed, that have the 
> effect of preventing delivery of a call.
> 
> So it seems you are looking for another attribute that can be input to 
> a policy engine that makes such decisions.
> 
> So, on one hand its desired to indicate that the caller wants this 
> call to receive special treatment, and then there is the issue of 
> determining if the caller is entitled to ask for such treatment.
> 
> the treatment is required. Its been stated that this is intended for 
> use by the UAS. But the kinds of services we are discussing bypassing 
> are in general provided on behalf of the UAS, so I think it still 
> applies.
> 
> >>>> Either it is routed to some alternative device that terminates 
> >>>> the call instead of the intended device, or else it is routed 
> >>>> through some device that simply acts as an intermediary, still 
> >>>> allowing the
> >> call to reach
> >>>> Anything that routes to someplace other than the intended device 
> >>>> is of dubious appropriateness when the r-uri is a GRUU. Again I'd 
> >>>> be interested to hear some examples.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Nov 2011 23:09:07 +0100

Hi, 

> It seems a little dangerous to say that a PSAP callback would bypass all application servers.  Sometimes network routing functions are implemented in devices that architecturally (because of how they 
> attach to the network) are considered application servers.  Consider the 3GPP VCC-AS for example...

I didn't mean to say that callbacks by defualt would always bypass all application servers - the operator will have to configure that. The point is that the operator shall be able to configure bypassing (and/or other policies) for callbacks. 

> Would inclusion of RPH sufficiently address potential server congestion?

I see no reason why not. Personally I think RPH, with a callback namespace, could also work for the bypassing, but there seems to be some issues about whether that is correct usage of RPH.

Regards,

Christer

> But, in general, the idea is to not forward requests to application 
> servers at all (even if the call would eventually still reach the 
> correct device), e.g. due to the the risk of congestion etc (as 
> indicated by James).
> 
> wants this call to receive special treatment, and then there is the 
> issue of determining if the caller is entitled to ask for such 
> treatment.
> 
> Correct.
> 
> indicator that the treatment is required. Its been stated that this is 
> intended for use by the UAS. But the kinds of services we are 
> discussing
> Yes. There needs to be a way for the network, when it receives a 
> request claiming to be a PSAP Callback, to determine that the call 
> comes from a PSAP. There might be different ways of doing that, 
> depending on networks, environments, operator agreements etc.
> 
> Regards,
> 
> Christer
> 
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 17:12:09 -0500

Thanks Christer.

Maybe it's not easy to implement, but I'm uncomfortable that a device, once used to place a 911 call, is permanently marked as accessible to an unlimited number of calls from entities that pass the "I am a PSAP" test.

tim

> Sent: Wednesday, November 30, 2011 4:05 PM
> To: Dwight, Timothy M (Tim); Paul Kyzivat
> Cc: [email-masked]
> I will double check, but I don think that there is any time 
> limit (at least not a "relatively short" one) for a call to 
> be considered and treated as a callback. The network entities 
> that makes the prioritization may not even know when the 
> associtaed emergency call was made (so, if there were some 
> time limit I think the callback would need to contain timing 
> information).
> 
> Regards,
> 
> Christer
> 
> On Behalf Of Dwight, Timothy M (Tim)
> Does there need also to be some "time limit"?  ISTM that 
> after some [relatively short] period of time, a call from a 
> PSAP is no longer a "call back" and needn't be prioritized.  
> 
> tim
> 
> possible to 
> be input to 
> indicator that 
> itself, but 
> > >>>> reach the intended destination, is probably benign. 
> (Do you have 
> > >>>> a
> > >>>> counter-example?)
> > >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 06:22:46 +0800

> Yes. There needs to be a way for the network, when it receives a request claiming to be a PSAP Callback, to determine that the call comes from a PSAP. There might be different ways of doing that, d…

I'm not happy with the idea of crafting special mechanisms just to 
indicate "this is a PSAP calling" or "this is an emergency callback".

IMO it would be better to use *some* standard mechanism, together with 
policies driven off of it.

E.g. use P-Asserted-ID with a special URI to indicate the caller is a 
PSAP, and then policies that allow/forbid use of Priority:emergency and 
RP based (in part) on whether the caller has this ID.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 30 Nov 2011 17:18:57 -0500

phonebcp says:
ED-64/SP-34 Devices device SHOULD have a globally routable URI in a
   Contact: header field which remains valid for several minutes past
   the time the original call containing the URI completes unless the
   device registration expires and is not renewed.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 06:40:19 +0800

> Maybe it's not easy to implement, but I'm uncomfortable that a device, once used to place a 911 call, is permanently marked as accessible to an unlimited number of calls from entities that pass the…

The phone can limit this by using a unique temp-gruu for its emergency 
calls, and remembering the temp-gruu for only as long as it wants to 
allow callbacks. Then if it gets a call to gruu remembered this way it 
can honor it, and otherwise not.

This is independent of the mechanisms by which the call bypasses network 
"services" to reach the device.

Done this way, the device can still be subject to undesired priority 
callbacks. But the only cost is detecting and rejecting them, which 
should not be a great burden.

	Thanks,
	Paul

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 17:42:25 -0500

That'll work.  Thanks, Brian.

Tim

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2011 4:19 PM
> Cc: Christer Holmberg; Paul Kyzivat; [email-masked]
> > Maybe it's not easy to implement, but I'm uncomfortable 
> that a device, once used to place a 911 call, is permanently 
> marked as accessible to an unlimited number of calls from 
> entities that pass the "I am a PSAP" test.
> > 
> > tim
> > 
> wants this

---

From: Marc Linsner <[email-masked]>
Date: Wed, 30 Nov 2011 18:14:44 -0500

Tim,

If you ask the public safety community, they will ask for a 1 hour time
period for special callback treatment.   They don't expect special status
beyond that time period.

-Marc-

-----Original Message-----
From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 30 Nov 2011 17:12:09 -0500
To: Christer Holmberg <[email-masked]>, Paul Kyzivat
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead
of eGRUU

>Thanks Christer.
>
>Maybe it's not easy to implement, but I'm uncomfortable that a device,
>once used to place a 911 call, is permanently marked as accessible to an
>unlimited number of calls from entities that pass the "I am a PSAP" test.
>
>tim
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Nov 2011 20:32:36 -0500

Here's a slightly different model:

(1) The UA requests (or automatically gets) a special emergency (temp) GRUU; we can request this in some way, probably using a Contact parameter. sip.priority=emergency would probably work if we want to re-use something.

(2) The UA uses that GRUU in the emergency call. There is no need to mark it - the PSAP has no control over call handling at the emergency caller anyway, so it does the same thing whether the UA knows about special handling or not.

(3) The PSAP places a normal call-back. The proxy knows that this is a special GRUU that will only be used for emergency calls, so it can do all bypass actions it wants. Since the UA won't use this GRUU for "normal" calls, there is no abuse risk.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 10:54:00 +0800

> (1) The UA requests (or automatically gets) a special emergency (temp) GRUU; we can request this in some way, probably using a Contact parameter. sip.priority=emergency would probably work if we wa…

I'm *really* unhappy with the concept of special emergency temp gruus.
The mechanism for temp gruus is already complicated and heavy weight. 
Lets not complicate it further.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Nov 2011 22:07:22 -0500

I'm all for not complicating things, but so far, all other proposed solutions seem to fall short in one or more of:

- can't deal with CallID-mangling SBCs

- are subject to abuse attacks (various "plain" labels, such as RPH by itself)

- can't signal to the proxy to induce special (non-forwarding/blocking) call handling

One cop-out is that we just use temp-gruus and have the proxy recognize them on the outbound emergency call path. This obviously has other complications, but we seem to be running low on low-complexity solutions. (I'm not worried that somebody will, within the REGISTER refresh, call somebody with the same temp-gruu and then get this abused. The probability seems pretty low. I'm also willing to tolerate that call forwarding will fail within one hour of placing an emergency call if somebody uses a temp-gruu.)

Henning

On Nov 30, 2011, at 9:54 PM, Paul Kyzivat wrote:

> The mechanism for temp gruus is already complicated and heavy weight. Lets not complicate it further.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 11:21:29 +0800

> One cop-out is that we just use temp-gruus and have the proxy recognize them on the outbound emergency call path. This obviously has other complications, but we seem to be running low on low-comple…

Are you assuming that the special temp gruu works because the entity 
that assigns the gruu is also the one that is responsible for all the 
special feature handling/disabling?

That is a bit of a stretch, though it may be sufficient for IMS.

This doesn't work for any element that isn't party to the gruu 
assignment and validity algorithms.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Nov 2011 22:33:31 -0500

On Nov 30, 2011, at 10:21 PM, Paul Kyzivat wrote:

> Are you assuming that the special temp gruu works because the entity that assigns the gruu is also the one that is responsible for all the special feature handling/disabling?

Yes, or at least has some relationship with that element. For a GRUU to work, the inbound proxy has to know about it, so this seems at least plausible.

(That's part of the "complications" I mentioned earlier.)

> That is a bit of a stretch, though it may be sufficient for IMS.

I suspect it would work in most simple enterprise environments where all calls, in and out, traverse the same proxy.

> 
> This doesn't work for any element that isn't party to the gruu assignment and validity algorithms.

Indeed - the "complications"...

Again, we seem to run short of magic of a simple solution that is secure, requires no protocol extension anywhere and works in all architectures. I suspect we can get, at best, two of those three...

Henning

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Dec 2011 08:44:21 +0100

Hi, 

>(1) The UA requests (or automatically gets) a special emergency (temp) GRUU; we can request this
>in some way, probably using a Contact parameter. sip.priority=emergency would probably work if 
>we want to re-use something.
>
>(2) The UA uses that GRUU in the emergency call. There is no need to mark it - the PSAP has no 
>control over call handling at the emergency caller anyway, so it does the same thing whether 
>the UA knows about special handling or not.
>
>(3) The PSAP places a normal call-back. The proxy knows that this is a special GRUU that will
>only be used for emergency calls, so it can do all bypass actions it wants. Since the UA won't 
>use this GRUU for "normal" calls, there is no abuse risk.

That was exactly the original thinking behind the eGRUU.

>> Are you assuming that the special temp gruu works because 
>> the entity that assigns the gruu is also the one that is 
>> responsible for all the special feature handling/disabling?
> 
> Yes, or at least has some relationship with that element. For 
> a GRUU to work, the inbound proxy has to know about it, so 
> this seems at least plausible.
>

In case of roaming, the callback might traverse a transit network, and the visited network, so I guess the question is whether there is a need for such networks to be aware of PSAP callbacks (e.g. when making interconnect point selection etc)? 

NOTE: That question is not IMS specific :)

> I suspect it would work in most simple enterprise 
> environments where all calls, in and out, traverse the same proxy.

At least in IMS (but I assume also in other environements) you can not make such assumption.

Again, in roaming scenarios, where the calling UA is in a visited network, the emergency call might not traverse the home network, but the PSAP Callback will.

Regards,

Christer