Subject: [Sipping-emergency] General Question about Scope of this list

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Feb 2003 16:29:07 -0600

All

Since I wasn't in the initial concall for this list's creation, can I ask 
what the general scope is of this design team?

Is it SIP for e911/112 (sos@)?

Is it SIP for all Emergency Services (GETS, IEPREP, GTPS, FEMA, etc)?

Is it SIP for Gov/Military Preferential Emergency Communications (MLPP)?

Any combination of the 3 listed above?

The first 3 of the above qualify as "emergency", but in reading Henning's 
draft, that ID seems much skewed towards only the 1st case above, yet it is 
similar to this new list's name.

I'm just looking for guidance and boundaries, folks

cheers,
James

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Feb 2003 18:04:41 -0500

I'll answer the easy ones...

> Is it SIP for e911/112 (sos@)?

Yes.

> Is it SIP for all Emergency Services (GETS, IEPREP, GTPS, FEMA, etc)?

No. Despite the common word 'emergency', these two have very little to 
do with each other, in my opinion.

> Is it SIP for Gov/Military Preferential Emergency Communications (MLPP)?

No.

> Any combination of the 3 listed above?

I really don't want to replicate IEPREP. That already is a highly 
effective working group.

> 
> The first 3 of the above qualify as "emergency", but in reading 
> Henning's draft, that ID seems much skewed towards only the 1st case 
> above, yet it is similar to this new list's name.
> 

Given that this confusion seems to be perennial, Gonzalo might want to 
update the web page.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 17 Feb 2003 17:27:45 -0600

>Given that this confusion seems to be perennial, Gonzalo might want to 

Might not be a bad idea to have a piece of text explaining what this design 
team is working on - and what is considered out of scope.

cheers,
James

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 21 Feb 2003 11:00:15 +0200

Henning,

> Given that this confusion seems to be perennial, Gonzalo might want to

Does it look clearer now?

http://www.softarmor.com/sipping/teams/emergency/

Gonzalo

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Feb 2003 09:18:58 -0500

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.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Feb 2003 12:21:29 -0600

At 09:18 AM 2/21/2003 -0500, Henning Schulzrinne wrote:
>Since the deadline for -00 I-Ds is Monday morning, I will submit the draft 
>as is.

sorry about the timing. I will send you comments today (FRIDAY).... I've 
been caught in several other battles that were to do with my writing 
something, and to be honest, those took priority. I should be finishing 
those up this afternoon, and can dedicate some time to your draft in time 
for you to review them.

cheers,
James

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 22 Feb 2003 13:54:38 -0600

>Since the deadline for -00 I-Ds is Monday morning, I will submit the draft 

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.

cheers,
James

---

From: Allison Mankin <[email-masked]>
Date: Sat, 22 Feb 2003 14:23:33 -0800

Henning, 

Apologies for not paying enough attention to this list.  I am somewhat
concerned with the scope of your requirements.  We had an AD/Chair discussion
of restricting initial work to Last-Mile, with explanation of the benefit
of an initial, fairly tractable and useful problem set.   This is not following
that restriction.

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 17:40:21 -0500

Allison,

if you're referring to our joint phone discussion (the only one I was in 
on), I took away from that conversation that requirements for both 
aspects were needed. Indeed, I believe that we're seriously 
short-changing needed developments if we can't get to work on the 
end-to-end requirements soon. Last-mile will not support VoIP terminals 
except if these are in local PBX-mode only (i.e., attached to a PSTN 
gateway in the same building or on the same campus). While public 
IP-accessible ECC may still be a few years away, private arrangements, 
either similar to onStar or corporate/campus security centers, seem 
likely sooner than that.

For what it's worth, the last-mile requirements are essentially the same 
requirements as a PBX with ACD.

Henning

---

From: Allison Mankin <[email-masked]>
Date: Sat, 22 Feb 2003 14:54:10 -0800

Henning,

The problem with expressing all the requirements is that it
will not guide the work and discussion on the shorter-term goals
properly.

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 18:00:17 -0500

The last-mile requirements are in a separate section, so I'm not sure I 
see the problem. (Besides, quite frankly, I'm not sure what needs to be 
done, SIP-wise, for the short-term issues. As I said, this is 
effectively an ACD with conference recording. It might be useful to say 
that, but I think we might make some progress if we can identify, at 
least within the design team, the likely areas needing work for the 
last-mile case. There are, to be sure, other useful ways to apply IP in 
the last-mile case, but those are effectively geopriv territory, namely 
the authorized retrieval of location information given an E.164 identifier.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 18:21:57 -0500

> 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.

Thanks for your extensive comments. Remarks inline where needed. I'll 
split my response to keep things manageable.

> #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.
> 
> different than the US model where you call (or are patched through to) 
> the local ECC.

Hmm, isn't that the same as having a large regional PSAP in the US? I 
think they are called consolidated PSAP.

Thus, I'm not sure how my definition contradicts the London example - 
the London ECC "receives emergency calls within a specific geographic 
area and
dispatches emergency services, such as fire, police and rescue services."

> 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.

Actually, last-mile is not visible to the "subscriber", so DSL or 
whatever are simply the way that the ECC connects to the PSTN selective 
router. (I suspect US PSAPs would not choose a cable modem as their 
access technology, but that's a discussion we don't need to have here.) 
Maybe your remark hints at a broader lack of common understanding what 
'last mile' means. I'm referring to the model described in the NENA TID 
that I sent around yesterday, where IP only replaces the analog or 
digital trunk from the last switch to the PSAP. In that model, there is 
no way that a subscriber can directly send a SIP request to the PSAP.

You obviously raise a good point that illustrates that even in a 
near-term deployment of VoIP over a current cable plant causes 
difficulties for the last-mile model. (In NJ, the bastion of home rule, 
a PSAP might cover only one square mile, so we get DSL service out of a 
neighboring community.)

to be continued

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 18:33:14 -0500

> 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."

I don't know whether this is a NA term. I qualified it.

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

Given the lack of documentation on emergency call network architectures, 
I suspect we'll be hard-pressed to find out for sure. I'm hoping that 
somebody in the larger SIPPING community can suggest appropriate I18N 
terminology.

> 
> 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).

Defined, by cribbing from the NENA master glossary:

(E9-1-1) Control
Office
The Central Office that provides the tandem switching of 9-1-1calls. It 
controls
delivery of the voice call with ANI to the PSAP and provides Selective 
Routing,
Speed Calling, Selective Transfer, Fixed Transfer, and certain 
maintenance functions
for each PSAP. Also known as 9-1-1 Selective Routing Tandem or Selective 
Router.

> 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.

Since the IETF can only specify "must implement", rather than "must 
use", I should have stated this as an implementation constraint. 
Reworded as "Implementations MUST support confidentiality".

TBCont'd.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 20:00:04 -0500

>    - Proper call routing to the PSAP(based on caller location)

Since the call is already identified as an emergency call, I don't see 
the need for any additional flags. (Adding such a flag mechanism would 
introduce additional attack vectors, for example.)

> header of the UAC and any/all Proxies involved in the call routing) for 

These items are enumerated in the beginning of the end-to-end section. 
They do not apply to the last-mile architecture.

> 
> 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:
> 
> 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.

Noted. Added 'integrity' under call setup.

> 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). 

Where is that Internet definition from? I would define anything that's 
on an IP network connected to the global Internet as an Internet device.

> 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.

Indeed.

> "... 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.

removed 'small'

> 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.

Note that the text speaks of finding the correct IECC, not of 
determining the location. The idea is that if a UA knows its location 
(via whatever means, including the ones you mention), it can directly 
query a location-to-IECC mapping service and then contact the IECC. This 
model has trust advantages since the UA can choose whatever mapping 
service it considers trustworthy ahead of time, get back a reply it can 
trust (since it presumably has made sure it's talking to the right 
directory service) and can then easily use standard server 
authentication mechanism to detect that it is indeed talking to the 
desired IECC. This makes the trust problem much more tractable. In 
effect, the caller gets to choose its "PSAP certifying authority" 
without every PSAP having to be accredited by one certifying authority. 
I'm hoping that this type of mechanism is both implementable and can 
allay the fears of Jon of talking to the corner PSAP run by the Sopranos.

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

I hope you don't expect me to know that :-) I suspect that they don't 
move often, but consolidations, in particular, seem not uncommon. Also, 
you'd not only need all 5,000 US PSAPs, but every PSAP-equivalent in the 
world. Since you probably don't want to download the whole table over a 
wireless interface each time two PSAPs merge, you then need a 
synchronization mechanism. I suspect this can all be done (after all, 
this isn't all that different than downloading a version of Zagat's on 
your PDA and there are lots more restaurants in NYC than they are PSAPs, 
I suspect...), so I'll mention it as a possibility.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Feb 2003 20:35:12 -0500

> 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.

I don't think this is a big issue. We have running code for that, at 
least for the US (using a company that has a proprietary interface 
database that offers a geo-to-jurisdiction mapping). Indeed, existing 
telematics services such as OnStar use such mapping services, so this 
seems like a manageable problem on the user end. It's much harder on the 
backend if you want to support several competing providers of such 
translation services - you essentially get back to the 
registrar-registry problem for DNS. I suspect that this is far beyond 
where we want to go in this effort.

> 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.

Yes, I considered that implied in the mediated model, but I amplified this.

> 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).

If we do get SIP payphones, they'd convey the same information as today: 
the identity of the payphone and its location (since there's no need for 
personal authentication), so I guess this doesn't seem to raise any new 
issues.

My TBD referred to the question as to whether there are jurisdictions 
that allow terminal selective anonymity, but I guess this question is 
unanswerable.

> covered in (instead of having the reader read the whole ID before 
> knowing a certain topic is indeed covered).

I've added a bit of verbiage up front, but the beginning of the 
End-to-End section does point to the 'who' and 'where' sections.

> call, it MUST route the call to the appropriate ECC or IECC.

Noted.

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

The I-D editor picked it up at 12:55 on Friday, so I'll create a -01 
version. It's at 
http://www.cs.columbia.edu/sip/drafts/draft-schulzrinne-sipping-emergency-req-01.pdf

Thanks again for your comments.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 23 Feb 2003 11:54:18 -0600

At 06:21 PM 2/22/2003 -0500, Henning Schulzrinne wrote:
>Thus, I'm not sure how my definition contradicts the London example - the 
>London ECC "receives emergency calls within a specific geographic area and

Many are not educated on the details or implementations of 911 and e911. 
Most in fact, believe this is a local issue only (meaning limited to a 
city, or region of a large city). I wasn't really commenting on 
contradictions (sorry if it came across that way) as educating how things 
are now. IP will only expand the territories,

>>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.
>
>Actually, last-mile is not visible to the "subscriber", so DSL or whatever 
>are simply the way that the ECC connects to the PSTN selective router. (I 
>suspect US PSAPs would not choose a cable modem as their access 
>technology, but that's a discussion we don't need to have here.) Maybe 
>your remark hints at a broader lack of common understanding what 'last 
>mile' means. I'm referring to the model described in the NENA TID that I 
>sent around yesterday, where IP only replaces the analog or digital trunk 
>from the last switch to the PSAP. In that model, there is no way that a 
>subscriber can directly send a SIP request to the PSAP.

There are several installations that use HFC as primary line. They are 
installed in most of the largest cities in the US. The products are from 
Arris (co-owned by Nortel at one time, I use to work on the Nortel team of 
that partnership several years ago). Dallas/Fort Worth (where I am) has had 
the opportunity to convert over to HFC and off wire-pairs for more than a 
year for my primary phone service. The provider is a little company called 
AT&T. The business goal of AT&T is to penetrate all the 32 NFL cities 
(their term).

At the MSO Headend, there is connectivity to a Class 5 switch (either 
co-located, or feed to it). Thus, this MSO might be quite a ways outside of 
the PSAP jurisdiction (likely not 100 miles in AT&T's case in the near term 
- but we are talking about years from now also)

>You obviously raise a good point that illustrates that even in a near-term 
>deployment of VoIP over a current cable plant causes difficulties for the 
>last-mile model. (In NJ, the bastion of home rule, a PSAP might cover only 
>one square mile, so we get DSL service out of a neighboring community.)
>
>to be continued
>

cheers,
James

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Feb 2003 13:28:03 -0500

> There are several installations that use HFC as primary line. They are 

We're still not connecting. HFC might well be used for regular 
telecommunications subscribers, but the 'last-mile' model is constrained 
to the case that the PSAP uses IP access, while the emergency callers 
only use regular PSTN, however they get there.

> Arris (co-owned by Nortel at one time, I use to work on the Nortel team 
> of that partnership several years ago). Dallas/Fort Worth (where I am) 
> has had the opportunity to convert over to HFC and off wire-pairs for 
> more than a year for my primary phone service. The provider is a little 
> company called AT&T. The business goal of AT&T is to penetrate all the 
> 32 NFL cities (their term).
> 
> co-located, or feed to it). Thus, this MSO might be quite a ways outside 
> of the PSAP jurisdiction (likely not 100 miles in AT&T's case in the 
> near term - but we are talking about years from now also)

That's all true and important for the end-to-end model, but completely 
irrelevant to the last-mile model.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 23 Feb 2003 20:39:48 -0600

At 08:00 PM 2/22/2003 -0500, Henning Schulzrinne wrote:

>Since the call is already identified as an emergency call, I don't see the 
>need for any additional flags. (Adding such a flag mechanism would 

I'm not proposing them, but they still might become a requirement from the 
jurisdiction. My list above was a possible projection of what an IP list 
could look like. I believe the priority flag was and is mentioned not as 
expected, just possible (that's why I use the word "any" - if there aren't 
any, you can't include them)

>They do not apply to the last-mile architecture.

Fair. I believe you can use them how you like. If you believe this list (or 
the section half of the whole list) is applicable to only the e2e section, 
then by all means include what you feel is appropriate. I was only offering 
a list, not 'the' list.

>>which most people define as traffic passing between two Tier 1 ISPs).
>
>Where is that Internet definition from?

Patrik Fältström is one of my coworkers who is part of this discussion 
within Cisco frequently. This is his tenuous definition - though he speaks 
it not in the absolute sense, but hesitantly as it hasn't been agree upon 
anywhere in the community. My use it as a guide, though opinions vary 
(obviously).

>I would define anything that's on an IP network connected to the global 
>Internet as an Internet device.
>
>>If the Proxy is not local to the UA, then the issue of how this non-local 
>>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 
>Note that the text speaks of finding the correct IECC, not of determining 
>the location. The idea is that if a UA knows its location (via whatever 
>means, including the ones you mention), it can directly query a 
>location-to-IECC mapping service and then contact the IECC.

But.... doesn't the UA *not* know the IP address of the PSAP? If it doesn't 
in the INVITE, then the Proxy has to direct the INVITE (with the sos@) 
towards the proper PSAP. This will require the Proxy to know which PSAP to 
do to (unless there is only one in the area - in the case of a large 
regional service). Maybe I'm missing something...?

>This model has trust advantages since the UA can choose whatever mapping 
>directory service) and can then easily use standard server authentication 
>mechanism to detect that it is indeed talking to the desired IECC. This 
>makes the trust problem much more tractable. In effect, the caller gets to 
>choose its "PSAP certifying authority" without every PSAP having to be 
>accredited by one certifying authority.

That will never happen

>I'm hoping that this type of mechanism is both implementable and can allay 
>the fears of Jon of talking to the corner PSAP run by the Sopranos.
>
>
>I hope you don't expect me to know that :-) I suspect that they don't move 
>often, but consolidations, in particular, seem not uncommon. Also, you'd 
>not only need all 5,000 US PSAPs, but every PSAP-equivalent in the world. 
>Since you probably don't want to download the whole table over a wireless 
>interface each time two PSAPs merge, you then need a synchronization 
>mechanism.

how hard would this be to include in something like a DHCP configuration 
download? Or have the UA periodically do something like an OPTIONs query to 
the Proxy it knows, and exchange the necessary information to learn the 
available choice in the background.

>I suspect this can all be done (after all, this isn't all that different 
>than downloading a version of Zagat's on your PDA and there are lots more 
>restaurants in NYC than they are PSAPs, I suspect...), so I'll mention it 
>as a possibility.
>

cheers,
James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 23 Feb 2003 20:53:44 -0600

At 01:28 PM 2/23/2003 -0500, Henning Schulzrinne wrote:
>to the case that the PSAP uses IP access, while the emergency callers only 
>use regular PSTN, however they get there.

now I understand your direction....

>>company called AT&T. The business goal of AT&T is to penetrate all the 32 
>>NFL cities (their term).
>>of the PSAP jurisdiction (likely not 100 miles in AT&T's case in the near 
>>term - but we are talking about years from now also)
>

noted (knowing now the direction you are referring to).

BTW - I'm fine with all your other responses to the listed comments and 
questions.

cheers,
James

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Feb 2003 23:03:04 -0500

> within Cisco frequently. This is his tenuous definition - though he 
> speaks it not in the absolute sense, but hesitantly as it hasn't been 
> agree upon anywhere in the community. My use it as a guide, though 
> opinions vary (obviously).

Pardon my timidity, but I'd rather not use this document to attempt a 
definition of Internet beyond the generally understood "a network of 
networks"... If Patrik wants to write a separate draft to clarify the 
internet/Internet/intranet/whatever distinction for current needs, it 
would be appropriate to cite it.

>> query a location-to-IECC mapping service and then contact the IECC.
> 
> 
> But.... doesn't the UA *not* know the IP address of the PSAP? If it 
> doesn't in the INVITE, then the Proxy has to direct the INVITE (with the 
> sos@) towards the proper PSAP. This will require the Proxy to know which 
> PSAP to do to (unless there is only one in the area - in the case of a 
> large regional service). Maybe I'm missing something...?

Assumptions: (1) UA knows its own location, e.g., long/lat.
(2) UA knows at least one translation service that converts long/lat to 
ECC identity. How the UA knows this service is a matter of 
configuration, but it might be reasonable to assume that these lookup 
services change rarely. (Even if one were to go out of business, since 
the query interface is standardized, it would be trivial for the 
survivor to buy the address at the Chapter 7 sale...)

These assumptions are not unreasonable since there are commercial 
services that offer this type of service. They are currently not 
designed to be used by millions of users, but this seems like a problem 
that good system engineering could solve. The problem is much more 
tractable than even the most modest-sized search engine, say, both in 
terms of query rate (a few queries/second), stability of the data and 
number of entries (thousands).

Process: UA contacts this abstract service and gets back the SIP URI of 
the geographically appropriate ECC.

Is this clearer?

> 
>> This model has trust advantages since the UA can choose whatever 
>> mapping service it considers trustworthy ahead of time, get back a 
>> reply it can trust (since it presumably has made sure it's talking to 
>> the right directory service) and can then easily use standard server 

I'm trying to avoid the discussion of this since we will likely not get 
anywhere speculating. I'm trying to point out ways that we can avoid 
needing central authorities, while not preventing their emergence. In my 
opinion, we should provide the best (most reliable, secure, scalable, 
...) tools possible and then help the operational community do the right 
thing.

> download? Or have the UA periodically do something like an OPTIONs query 
> to the Proxy it knows, and exchange the necessary information to learn 
> the available choice in the background.

The data volume remains the same, so I'm not sure how "background" helps.

In any event, the draft now mentions synchronization-of-local-data as 
one possibility. Since this is a requirements document, I'm trying to 
exhaustively list all possible options, not pick favorites. Abstractly, 
I don't see any other possibilities beyond "UA knows itself" (local 
data), "UA asks somebody" (UA queries network directory) or "UA asks 
somebody that asks somebody" (UA sends request to proxy that queries 
directory or has local knowledge; this can recurse, obviously).

Henning

---

From: Allison Mankin <[email-masked]>
Date: Sun, 23 Feb 2003 20:52:33 -0800

Henning,

 Since this is a requirements document, I'm trying to
 exhaustively list all possible options, not pick favorites.

A requirements document should be more generic.  There's 
almost a sense that you and James are writing an quasi-RFP
for US and European centers.  Your words give the sense of 
avoiding "the" solution by giving ranges of them.

The goal should be to give the problem with some clarity to
SIPPING so that the group can determine 1. if it's a necessary
one for the WG.  2. if it's one that can be done with existing 
SIP capabilities and whether they have issues such as security
strengths that might need modifications (a number of times SIPPING
has found that the feature was fine, but it needed some normative
modification).  3.  if not, what requirements there are for new
SIP capabilities.  I see far less generic material in the current
draft.

I too am working to deadlines this weekend, so this comment must
be brief, but I have a real concern for what we will see from
this draft.

Allison