[Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne-sipping-emergency-req-00

["James M. Polk" <[e-mail]>]

At 09:18 AM 2/21/2003 -0500, Henning Schulzrinne wrote:
>Unfortunately, I have received no comments on 
>http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-00.pdf
>
>Since the deadline for -00 I-Ds is Monday morning, I will submit the draft 
>as is.

Henning (and all)

Because I've had much writing of my own this past few weeks, and with the 
deadline approaching for -00 IDs, I apologize for this coming so late.

Here are a few questions and comments regrading this ID:

#1 - From the Abstract: you mention MEGACO and H.323 (not an IETF protocol) 
- yet MGCP is used a fair amount for IP control within the US.

#2 -  PSAP stands for "Public Safety Answering Point" (not "...Service 
Access..."). I was corrected recently too by our NENA engineer within Cisco.

#3 - "Emergency call center (ECC): An emergency call center (ECC) receives 
emergency calls within a specific geographic area..."

Comment: London has what you refer to as ECCs, but the have all calls from 
the surrounding regional area come into a single center, the Call taker(s) 
determines where the call is coming from, then the emergency personnel are 
dispatched to the appropriate location from that centralized ECC. In other 
words, local emergency personnel are not called, they are dispatched by the 
ECC in London.

This might be a subtle difference to your intent, but it is fairly 
different than the US model where you call (or are patched through to) the 
local ECC.

#4 - From section 4 "Last Mile" you have omitted Cable access. I mention 
this because existing HFC Broadband connectivity can be as much as 100 
miles away from the MSO Headend facility. This could easily have an affect 
on which ECC (PSAP is appropriate to contact). This is in contrast to DSL 
which is typically limited to 22,000 ft from the CO, with most not possible 
at distances greater than 15,000 due to the poor cables in the ground. This 
limits the jurisdictional boundaries that can be crossed by this technology.

#5 - Also from section 4 "Last Mile"

I don't believe CAMA trunks should be "....so called..." as you do in the 
second paragraph of the indented paragraph there

#6 - From M8" ...from the selective router."

Comment: Is this functionality (or device) used outside North America. If 
it is NA exclusive, the text should state that; possibly with a caveat with 
something to the effect of ".... and similar functionality utilized in 
other parts of the world."

If the Selective Router is used throughout the world (or at least a lot of 
it), then the text could state that.

Another comment: "Selective Router" is an undefined term at this point, and 
not know to too many people within the IETF (if even a handful).

#7 - From M10 "Confidentiality" I think the word MUST is a problem. I 
believe this should be the goal, but not it if causes the call to fail, or 
be delayed. I believe this should be a SHOULD, and state that this is a 
goal, with some provision to determine that if a call is the threshold of 
stability due to this function, that it should be abandoned in place of 
receiving the call in the clear.

#8 - Suggested text for consideration (likely in the Intro, as it has to do 
with everything further into this document):

"Current North American Public Safety Answering Points (PSAPs) want 3 
things during a traditional E911 call (in this order of importance):

    - The call completed
    - The callback number
    - The location of the caller

For that call to occur over IP, 5 things are likely to be needed:

    - Proper call routing to the PSAP(based on caller location)
    - The call
    - Any priority flags
    - The location of the caller
    - A valid (should be verifiable) Contact Header (or mandatory Via 
header of the UAC and any/all Proxies involved in the call routing) for 
callback

What's not so obvious is whether there needs to be further (any?) security 
involved that could fail the call. If security considerations are 
necessary, with the full realization that the emergency call could fail if 
they are not met, then the following is the minimum to be included in the 
list above:

    - Assurance that none of the signaling (headers) have been munged"

This is from my unpublished framework ID on this subject, but it could be 
easily used in this doc. I would stress that at least the first 3 bullets 
are included here, as this is exactly what PSAPs want today.

#9 - From section 5

"End-to-end emergency calls originate on an Internet device, traverse IP 
networks and terminate on an IP capable ECC (IECC)."

Comment: this can be a moderately misleading statement. The most likely 
event or infrastructure will have the Emergency call hit the first Proxy 
and then travel straight to the local IECC (and not across the Internet - 
which most people define as traffic passing between two Tier 1 ISPs). If 
the Proxy is not local to the UA, then the issue of how this non-local 
proxy will know where the local PSAP is relative to this UA making the 
emergency call.

#10 - From Section 5.2, 2nd sentence:

"... ECCs only serve a small region ..." This isn't true in London that I 
know of. I don't know the exact nature of other major cities in Europe of 
Asia. Regardless, this statement made is not universally true, and has a 
major example where it isn't. Text couching this statement is recommended.

#11 - From section 5.2, 2nd paragraph, 3rd sentence:

"In caller-based resolution, the caller's UA consults a directory and 
determines the correct IECC based on its location."

Comment: This is omitting the possibility of a Geopriv WG ID (you're aware 
of) and another ID you wrote in which the UA could have its location "feed" 
to in upon boot-up (via DHCP). Both IDs state that if the UA has its 
Geo-Loc present in the UA, some future functionality in SIP (not defined 
yet) could include the location information in a Header or MIME body, and 
not need this look-up (nor does it have to determine anything - as the 
location information is "just there" in the UA.

#12 - also from section 5.2, 2nd paragraph, last sentence:

"(It appears undesirable to have either the UA or every outbound proxy 
server contain a copy of
the location-to-ECC mapping since this table changes frequently.)"

Question: How often do any of these stated 5000 PSAPs move (as you elude to 
with this above comment)?

#13 - Also from section 5.2, last paragraph

"Depending on the location, any of several ten thousand destinations could 
be valid."

comment: this seems to contradict the 5000 PSAPs within the US, unless you 
are referring to the total number of PSAP-like IECC and ECCs that exist 
throughout the world. If so, a brief mention of this would relieve 
confusion regarding this seemingly out of place number of destinations.

Further, I believe it will be a burden on the Proxy to properly route the 
call regardless of how many destinations there can be. Having the location 
contained within the UA helps this. marrying some cross-functional code 
between SIP and either Geopriv or the available L2 (wireless) technology to 
determine the UA's location will greatly help this effort.

I believe jurisdictions will demand this functionality - and it will not be 
easy.

#14 - From I1:

"The system MUST reach the correct IECC regardless of the location of the 
caller."

I believe must be restated to:
"The system MUST reach the correct IECC with respect to the location of the 
caller."

#15 - From I8: Call setup latency

Comment: This requirement is the first to elude to the concept of the Proxy 
having to know what to do with UAs and their coordinates (and the look-ups).

This leads into a new requirement that I haven't seen yet from section 5: 
If the UA has its location, regardless of where the Proxy is, there is a 
need for the (or any) Proxy to know which PSAP to route the call to based 
on this location information.

#16 - From I9:

"A mandatory-to-implement protocol..."

seems like a partial sentence

#17 - From 5.3, 2nd paragraph, last sentence

"Emergency numbers are generally not meant for anonymous tips. [TBD: Are 
there any exceptions?]"

This is a viable and often used mechanism from pay phones within urban 
cities to quitely inform the police about something the call wants them to 
be aware of, yet have no record of who called (like calling in where a drug 
deal occurred or is about to occur).

#18 - From section 5.4, first paragraph

you earlier exploded the acronym ANI, but haven't for ALI here.

#19 - observation at this point in the document

I've made a few comments about Location of the caller, and this is the 
first real text that covers the subject. Therefore, I'd suggest that the 
Introduction briefly go through what section each general topic will be 
covered in (instead of having the reader read the whole ID before knowing a 
certain topic is indeed covered).

#20 - A new Requirement that I haven't read here (and one that should be 
considered for section 5.2, else section 5.4): If the UA provides its 
location (coordinate or civil), or the first (or any) Proxy knows (or 
learns by some other means) the location of the UA making the emergency 
call, it MUST route the call to the appropriate ECC or IECC.

This is hinted at, and talked around, but I think it should be stated for 
formally and robustly.
++++++++++++++++++++++++

this is from my first pass at the doc, I might have a few redundant 
comments or questions, or some out of place - this is likely cause by the 
lack of the intro explaining where each general topic will be covered 
(Comment # 19).

If you've already published this ID, I'll reproduce this list of questions 
on the main SIPPING list for general discussion.




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


cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"

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