Re: [Ecrit] PSAP Call Backs

["Brian Rosen" <[e-mail]>]

Couple of thoughts here:

In the past several months, I have been involved with a couple of instances
where call backs turned out to be very difficult because they are not marked
(in the PSTN).  Gunnar cited one:

A relay provider handles an emergency call.  The PSAP calls the deaf caller
back.  Relay providers often have a queue of calls waiting for an available
interpreter.  US regulation now (as of last week) says emergency calls and
call backs should get priority on the queue.  How does the relay provider
know that an incoming call is a call back?

Another one is a telephony service with incoming call restrictions.  An
example is a phone for a child where the parent controls who can call the
child.  The child makes an emergency call.  A callback is needed.  The call
restrictions would bar the call unless it was known that it was an emergency
call.

Besides marking, there needs to be some other phonebcp-like text.  For
example, a callback should not normally be diverted (call forwarding).  T
may (needs some discussion) need to get through if do not disturb is enabled
(for example, inadvertently).

As with incoming calls, some minimum standards are needed on the signaling.

I also want to point out that resource priority marking is NOT a good choice
for an overall callback mark, the same way that the Route header sos urn is
not a good choice for a resource priority mark.

Brian

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
James M. Polk
Sent: Friday, January 02, 2009 3:15 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
Subject: Re: [Ecrit] PSAP Call Backs

At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi all,
>
>In the last few months we have seen increased interest in the topic of
>PSAP call backs.
>
>Section 10 of  http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06
>says:
>
>    SP-36 Call backs to the Contact: header URI recieved within 30
>    minutes of an emergency call must reach the device regardless of call
>    features or services that would normally cause the call to be routed
>    to some other entity.
>
>More importantly, Section 13 says:
>
>    ED-73 Call backs SHOULD be determined by retaining the domain of the
>    PSAP which answers an outgoing emergency call and instantiating a
>    timer which starts when the call is terminated.  If a call is
>    received from the same domain and within the timer period, sent to
>    the Contact: or AoR used in the emergency call, it should be assumed
>    to be a call back.  The suggested timer period is 5 minutes.
>
>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed
>another solution based on marking the callback using the "sos" URI
>parameter.
>
>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name
>space/ proposes another solution by utilizing the Resource Priority
>Header.

within the namespace ID, the total thought (for PSAP callback) is here:

    This namespace will also be used
   for communications between emergency authorities, and MAY be used
   for emergency authorities calling public citizens. An example of
   the later is a PSAP operator calling back someone who previously
   called 9111/112/999 and the communication was terminated before it
   should have been (in the operator's judgment).

Notice this is all based on the MAY in the first sentence, therefore 
it can be considered an afterthought, i.e., something that can be 
utilized/specified later.

the "sos" parameter solution is more definitive, yet it should 
identify a priority marking (in SIP), given that there is already a 
defined way to do that in SIP, and a second way shouldn't be defined 
- as it will only lead to interoperability issues.


>So, here are my high-level questions:
>
>A) Do you think that you understand the requirements that lead to a need
>for a technical solution?
>
>B) Do you believe that more work beyond the mechanism described in Phone
>BCP is needed?
>
>Ciao
>Hannes
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit