Subject: [Sipping] emergency call-back scenarios and requirements

From: "Scott Keagy" <[email-masked]>
Date: Tue, 20 Apr 2004 04:43:02 -0700

Need to be specific in managing emergency call-backs (don't know if this
has already been discussed).

If I'm sips:[email-masked] as my call-back, and I have 3 devices
(one of which is in my wife's possession in a different state/country
while I'm traveling for work), I want to make sure that my wife doesn't
answer a call-back first and cut me out of the loop accidentally. I'm
sure she'd be happy to be aware of the incident (and stressed it's
happening), but it would be disconcerting to me to not have updates or
be able to provide more useful details to speed a response.

This is aggravated in an enterprise where you have multiple line
appearances with same phone number or identifier, and they can be in
separate states and answered by people with no real knowledge of or
vested interest in each other.

So here's a set of requirements (or best practice suggestions) to the
problem of handling emergency call-backs:
1) need to recognize when an inbound call to arbitrary subscriber is
related to an emergency incident. Would be useful classification for
applying call-based precedence/preemption policies (can argue all day
about whether or not this is a good thing, but having the nerd knob lets
the affected user make the decision), as well as recognizing when to
apply the rule of steering the call to a given device.

2) Default configuration of proxies to do a serial search for an end
device associated with a URI (as opposed to a forked/parallel search)
when the inbound call is recognized as an emergency callback.

3) The first device on the list of serial searches for emergency
call-backs is the last one cached that made an emergency call. Apply
whatever policies for remainder (for example, whatever is preferred
policy for normal calls, or perhaps a forced parallel/forked search to
get a quick response on any other related line if no response on primary
device).

4) This implies that all emergency calls with a reply-to or From: header
are from devices that are in the search-list for the URI in the reply-to
or From: header. Client devices should be able to verify whether this is
the case, and warn the user or administrator during configuration if
it's not the case)

Regards,
Scott

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Tue, 20 Apr 2004 18:10:01 -0500

> has already been discussed).

Isn't it enough to say that the Contact used for emergency calls SHOULD 
be a GRUU, and that call-backs made from emergency call centers MUST use 
the Contact of the original call, not the AOR indicated in the From: field?

--
Dean