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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 26 Feb 2003 16:16:14 -0500

inline.

- J

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2003 2:54 PM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: Re: [Sipping-emergency] Re: [Sipping-emergency]
> draft-schulzrinne -sipping-emergency-req-00
> 
> 
[snip]
> 
> I would like to identify any real work which isn't just "purchasing 
> requirements for PSAP RFP" in the trunk replacement part. Can you 
> identify anything?
> 

Well, there are a number of issues, I think, many of which you identify in
your section 4 (in M1-M12). Some other things include:

- For ISUP e911 trunks, ISUP encapsulation in SIP seems like a reasonable
way to carry signaling information between the selective router and the
IECC. What about for non-ISUP signaling systems?

- What sorts of URIs are used to represent IECCs (especially in light of M4
and and M12)?

- Are there any special rules for the distribution of credentials used for
authentication between IECCs and selective routers? How many IECCs are
associated with selective routers and vice versa?

- Are there any RTP requirements that emerge from M6?

Again, this might not require radical new extensions to the SIP protocol -
it's probably doable with more or less the tools we have today. But
depicting a framework and architecture in an I-D along with the section 4
reqs would make it easier for the industry to understand how this trunking
replacement solution fits in.

> I happen to think that while end-to-end or even first-mile (something I 
> haven't called out explicitly) does need geo information that the 
> problem can be scoped properly so that it does not interfere with 
> geopriv work. At this point, I don't see the need to specify in detail 
> how the PSAP gets the location of the caller. We know it needs to - I 
> don't think geopriv is going to change that. There are only two 
> plausible ways to convey location - in a 'using protocol' and in some 
> out-of-band retrieval mode using a geopriv-specific mechanism. I don't 
> think that level of detail is controversial or likely to change.
> 

If the PSAP is expected to retrieve or receive the location information over
IP, then I would argue we've moved into the realm of geopriv. If on the
other the PSAP derives this location information from an ALI interface, then
we don't need geopriv - but, ALI is only relevant to telephone numbers, at
least at the moment. Not all SIP endpoints will have telephone numbers, etc.

> Also, the PSAP selection problem can be partially solved with existing 
> (apparently non-controversial) items in geopriv, namely the DHCP items.
> 

PSAP selection isn't really the main problem here, I think. I agree that
DHCP could help with PSAP selection.

Certainly there hasn't been much controversy about the DHCP proposal to
date, but I would note that the WG is more focused on delivering a framework
and requirements that jumping into a solution. The DHCP solution is, as far
as I understand it, oriented towards informing a telephone where it lives.
The degree to which this entails moving location information (civil or
geospatial) over an open IP network will largely dictate whether or not DHCP
would have to meet the security and policy requirements of geopriv. Until
those requirements are finished, it's hard to establish how well the DHCP
solution meets them.

> Thus, as long as we assume that geopriv does its job, we can fill in the 
> other pieces and make progress, treating geopriv as a suitable black box.
> 
> Thus, if we scope the work properly, I don't see why we'd bump into 
> geopriv issues except saying "you guys over there, we'll need you, get 
> busy".
> 
> Henning
> 
_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Feb 2003 10:21:38 -0500

> your section 4 (in M1-M12). Some other things include:

At least from my vantage point, all of them are effectively the same 
requirements that apply to a PBX with ACD. Can you identify any that 
cannot be done with existing or in-progress SIP* work? At best, this 
could result in a draft similar to the end system requirements that 
Henry Sinnreich and others are putting together, but that seems to stray 
very far into "RFP list" territory.

> IECC. What about for non-ISUP signaling systems?

I don't see the advantage of carrying ISUP information across the IP 
trunk. The only information that's in a 911 call right now is the ANI. 
We know how to do that in SIP - stick a tel URI in the From header or 
use one of the NAI mechanisms to convey the ANI. (By definition, the ECC 
has to trust the selective router, so that model fits.)

> - What sorts of URIs are used to represent IECCs (especially in light of M4

I suspect that they'll tel URIs for now, SIP URIs later. What would be 
different about them?

> associated with selective routers and vice versa?

I suspect the number of ECCs per SR is smallish (no more than a 
handful). Assuming the SR uses SIP addressing, it knows that a certain 
ECC is addressed as, say, psap.fayette.co.ky.us (for the Fayette County, 
Kentucky PSAP). This knowledge has to be hard-configured, so standard 
TLS server certs will do the job.

> - Are there any RTP requirements that emerge from M6?

I don't see how call routing affects RTP. Call routing is just a policy 
within the ECC proxy, not very different from how an airline would 
manage their callcenter.

> it's probably doable with more or less the tools we have today. But

That's my perception as well.

> replacement solution fits in.

That's all useful (with the "RFP caveat" above), but doesn't solve the 
real problem of SIP terminals placing emergency calls.

> least at the moment. Not all SIP endpoints will have telephone numbers, etc.

The emergency call problem is not going to get solved in one step. After 
all, most wireless phones still only convey the most basic location 
information (cell sector). I don't see the benefit of delaying what we 
can do today.

However, saying that it doesn't work for all phones doesn't seem to be 
reason to delay making it work for most SIP endpoints (which will have 
or be able to get a phone number). Note that a SIP endpoint doesn't even 
have to have a permanent, addressable phone number to make traditional 
ALI work. You can assign what's known as an ELIN, which is a 
pseudo-number which is then mapped to a location. This is done for MLTS 
(multi-line phone systems) for 911 today - in a handful of states, it's 
even mandated by law for larger businesses. After all, many black-phone 
extensions without DID don't have real phone numbers, either.

> DHCP could help with PSAP selection.

I disagree. PSAP selection is *the* main problem for consumer and 
business VoIP emergency deployment. If you don't get that right, you've 
added minutes, at best, to the emergency call, as the confused call 
taker tries to figure out which part of the country the emergency call 
is from. I'm sure that if I call from where I live right now and reach a 
NY gateway, that my call will be sent to Lexington, MA instead of 
Lexington, KY...

While conveying location information automatically to the ECC is an 
important service, it is secondary to getting the call through. After 
all, we do without today for almost all wireless calls and all 
telematics (OnStar, etc.) calls.

> as I understand it, oriented towards informing a telephone where it lives.

Correct (or mostly, as it may only be able to identify the location of 
the switch or access point).

> those requirements are finished, it's hard to establish how well the DHCP

While I can see that kidnapping-is-us may not want its victims to find 
out where they are, I'm having a hard time seeing how this information 
provides anything that isn't visible to any human being in the same place.

Even if we ignore the particular mechanism for getting the location 
information to the device (after all, there are likely to be many 
different ones, from local GPS to various query mechanisms), the 
remainder of the architecture doesn't really change.

Henning