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

[Paul Kyzivat <[e-mail]>]

On 12/1/11 5:00 AM, James M. Polk wrote:
> At 01:50 PM 11/30/2011, Paul Kyzivat wrote:
>> On 12/1/11 3:22 AM, Christer Holmberg wrote:
>>>
>>> Hi,
>>>
>>>> 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?
>>>
>>> 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.
>>
>> 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.
>
> 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 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

> 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
>>>
>>>
>>> On 11/30/11 6:22 PM, Christer Holmberg wrote:
>>>>
>>>> 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.)
>>>>
>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>>
>>>>>>> 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: [e-mail] [[e-mail]] On Behalf Of
>>>>>> Henning Schulzrinne [[e-mail]]
>>>>>> Sent: Tuesday, November 29, 2011 7:41 PM
>>>>>> To: Janet P Gunn
>>>>>> Cc: Paul Kyzivat; Adam Roach; ECRIT; [e-mail]
>>>>>> 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
>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>> To: Hadriel Kaplan
>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>> Cc: Adam Roach<[e-mail]<mailto:[e-mail]>>,
>>>>>> ECRIT<[e-mail]<mailto:[e-mail]>>, Paul Kyzivat
>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>> Date: 11/28/2011 03:19 PM
>>>>>> Subject: Re: [Ecrit] PSAP Callback indication:
>>>>>> Resrouce-Priority instead of eGRUU
>>>>>> Sent by: [e-mail]<mailto:[e-mail]>
>>>>>> ________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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: [e-mail]<mailto:[e-mail]>
>>>>>> [mailto:[e-mail]] 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
>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>
>
>