Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00
Henning Schulzrinne <hgs@cs.columbia.edu> Thu, 27 February 2003 15:19 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07719 for <sipping-emergency-archive@odin.ietf.org>; Thu, 27 Feb 2003 10:19:02 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFT3m27345 for sipping-emergency-archive@odin.ietf.org; Thu, 27 Feb 2003 10:29:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFT3p27342 for <sipping-emergency-web-archive@optimus.ietf.org>; Thu, 27 Feb 2003 10:29:03 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07679 for <sipping-emergency-web-archive@ietf.org>; Thu, 27 Feb 2003 10:18:29 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFT1p27324 for <sipping-emergency-web-archive@ietf.org>; Thu, 27 Feb 2003 10:29:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFS8p27249 for <sipping-emergency@optimus.ietf.org>; Thu, 27 Feb 2003 10:28:08 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07635 for <sipping-emergency@ietf.org>; Thu, 27 Feb 2003 10:17:34 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1RFLR7T000255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Feb 2003 10:21:28 -0500 (EST)
Message-ID: <3E5E2D02.30406@cs.columbia.edu>
Date: Thu, 27 Feb 2003 10:21:38 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: sipping-emergency@ietf.org
Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00
References: <15A2739B7DAA624D8091C65981D7DA8101214E5A@stntexch2.va.neustar.com>
In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E5A@stntexch2.va.neustar.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
> 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 Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
- RE: [Sipping-emergency] Re: [Sipping-emergency] d… Peterson, Jon
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… Henning Schulzrinne
- RE: [Sipping-emergency] Re: [Sipping-emergency] d… Peterson, Jon
- RE: [Sipping-emergency] Re: [Sipping-emergency] d… Peterson, Jon
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… Henning Schulzrinne
- RE: [Sipping-emergency] Re: [Sipping-emergency] d… Peterson, Jon
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… Henning Schulzrinne
- RE: [Sipping-emergency] Re: [Sipping-emergency] d… Peterson, Jon
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… James M. Polk
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… Henning Schulzrinne