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

[Henning Schulzrinne <[e-mail]>]

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

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.

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

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
> and and M12)?

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

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

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.

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

That's my perception as well.

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

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



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

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.


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

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.


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

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

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

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

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