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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Dec 2011 14:23:57 +0100

If you ask one particular public safety community.

If you go elsewhere you get completely different answers. At least that is what 3GPP found.

The problem then arises that if each regulator can have different views, how does one build such a timer into a terminal, that may be taken anywhere in the world by its owner, or may be taken out of the box anywhere in the world.

(Yes IMS does make various assumptions in terms of the duration of an emergency registration, which in IMS needs to be there to receive the potential callback, but I am not convinced we came up with an ideal answer.)

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marc Linsner
> Sent: 30 November 2011 23:15
> To: Dwight, Timothy M (Tim)
> Cc: [email-masked]
> Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead
> of eGRUU
> 
> 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
> >
> >> -----Original Message-----
> >> From: Christer Holmberg [mailto:[email-masked]]
> >> Sent: Wednesday, November 30, 2011 4:05 PM
> >> To: Dwight, Timothy M (Tim); Paul Kyzivat
> >> Cc: [email-masked]
> >> Subject: RE: [Ecrit] PSAP Callback indication:
> >> Resrouce-Priority instead of eGRUU
> >>
> >>
> >> 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,
> >>
> >> 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
> >>
> >> > -----Original Message-----
> >> > From: Paul Kyzivat [mailto:[email-masked]]
> >> > Sent: Wednesday, November 30, 2011 3:30 PM
> >> > To: Dwight, Timothy M (Tim)
> >> > Cc: [email-masked]
> >> > Subject: Re: [Ecrit] PSAP Callback indication:
> >> > Resrouce-Priority instead of eGRUU
> >> >
> >> > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote:
> >> > > 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.
> >> >
> >> > 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
> >> >
> >> > > tim
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: Paul Kyzivat [mailto:[email-masked]]
> >> > >> Sent: Wednesday, November 30, 2011 2:52 PM
> >> > >> To: Dwight, Timothy M (Tim)
> >> > >> Subject: Re: [Ecrit] PSAP Callback indication:
> >> > >> Resrouce-Priority instead of eGRUU
> >> > >>
> >> > >> 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
> >> > >>>> Subject: Re: [Ecrit] PSAP Callback indication:
> >> > >>>> Resrouce-Priority instead of eGRUU
> >> > >>>>
> >> > >>>> On 12/1/11 3:57 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.
> >> > >>>>>
> >> > >>>>> 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.
> >> > >>>>
> >> > >>>> 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
> >> > >>>> _______________________________________________
> >> > >>>> Ecrit mailing list
> >> > >>>> [email-masked]
> >> > >>>> https://www.ietf.org/mailman/listinfo/ecrit
> >> > >>>>
> >> > >>
> >> > >>
> >> >
> >> >
> >> _______________________________________________
> >> Ecrit mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >_______________________________________________
> >Ecrit mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ecrit
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit