[Sipping-emergency] [Fwd: Report on sipemergency call]

[Tom Taylor <[e-mail]>]

Apologies for the duplication.  I've forwarded Dean's minutes to the complete
sipping-emergency list so James can see where I'm coming from in doing the scenarios
document.  There was a bit of discussion following these minutes, so you may want to
consult the archives.

-------- Original Message --------
Subject: Report on sipemergency call
Date: Wed, 2 Apr 2003 13:49:52 -0600
From: Dean Willis <[e-mail]>
To: 'Jonathan Rosenberg' <[e-mail]>om>,   'Jon Peterson
([e-mail])' <[e-mail]>iz>,   'Rohan Mahy'
<[e-mail]>om>,   'Henning Schulzrinne' <[e-mail]>du>,   Taylor, Tom-PT
[CAR:5N00:EXCH]<[e-mail]>,   'Gonzalo Camarillo'
<[e-mail]>om>, <[e-mail]>om>,   Barnes, Mary
[NGC:B602:EXCH]<[e-mail]>
CC: <[e-mail]>


Given the scheduling confusion, the call proceeded with myself, Mary Barnes,
Tom Taylor, and Henning Schulzrinne in attendance. Sorry folks -- too many
irons in the fire, not enough wranglers to hold the cows down.

We discussed both the background and our current knowledge of the situation,
including some info that Henning just picked up at VON while talking to Nate
Wilcox of the Vermont 911 center.

Our current proposal is to proceed with developing a scenarios document
which will capture a little of the analysis as well as describing the known
main problem modalities. This will provide background for a "guidelines"
document that will help implementers understand the limitations and
effectively use existing specifications, perhaps including usage
conventions. Further analysis of the scenarios and guidelines will provide
input to Henning's longer-reaching requirements draft and potential future
work on more sophisticated solutions.

Tom and Mary have agreed to take a crack at drafting the scenarios document,
and will attempt to coordinate the vocabulary with that used in Henning's
requirements draft, for example "emergency call center" instead of PSAP.

Three "degrees of freedom" in the system were identified:

1) Phones
2) Gateways
3) Emergency call centers

Six "information sources" were identified:

1) User of the phone
2) The phone and supporting network
3) Gateways
4) The service provider and its routing systems
5) Emergency call centers
6) Third-party database providers

We identified five basic scenarios in the discussion:

1) Stationary SIP phones having known locations and operating with a local
gateway. This is essentially the "PBX" problem.

2) Stationary SIP phones having known locations operating with a gateway(s)
from a single operator with gateways in the PSAP regions in which phones are
located. This might be viewed as the "CLEC" problem.

3) Stationary or low-mobility phones sparsely distributed across a
relatively large geographical areas and operating with dynamically selected
gateways from a single operator or coalition of operators. This might be
labeled the "Vonage" problem, although we probably shouldn't call it that in
the draft.

4) Mobile SIP phones operating with a fixed (personal or enterprise)
gateway. This might be labeled the "dynamicsoft" problem as it describes my
office -- for example, we have a field office in KC with a Texas phone
number served by a gateway in Plano. Of course, we probably don't want to
use this name for the problem in the draft.

5) Mobile SIP phones operating with a personal gateway. This appears to be a
degenerate case of the #4, or did I miss something?

To Do items:

1) Gonzalo: Please add myself, Mary, and Tom to the sip-emergency list and
SIPPING design team.
2) Mary and Tom: Re-read Henning's draft and begin scenarios draft.
3) All of us: be thinking about how to address the scenarios, and give
consideration to internationalization issues.
4) Henning: Adapt requirements draft to consider scenarios draft and
likely-to-emerge practices draft.
5) Tom and Mary: Dig out references on existing PSAP functions and routing
models
6) Henning: Follow-up with Nate Wilcox from Vermont 911 center


Thoughts on proposed "practices" draft.

1) Should document what can be down now, with existing protocols.
2) Should document limitations of existing approaches. For example, in
scenario 5, 911 services aren't going to work right.
3) Should NOT identify extensions to protocols.
4) May identify helpful practices outside of pure SIP, such as providing DID
numbers for emergency call centers and databases correlating emergency call
centers with geoloc.


--
Dean




_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency