[Sipping-emergency] Re: Emergency-req: 8-12
Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 24 February 2003 04:02 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 XAA20286
for <sipping-emergency-archive@odin.ietf.org>;
Sun, 23 Feb 2003 23:02:41 -0500 (EST)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h1O4B3q13611
for sipping-emergency-archive@odin.ietf.org; Sun, 23 Feb 2003 23:11: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 h1O4B2p13608
for <sipping-emergency-web-archive@optimus.ietf.org>;
Sun, 23 Feb 2003 23:11:02 -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 XAA20281
for <sipping-emergency-web-archive@ietf.org>;
Sun, 23 Feb 2003 23:02:10 -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 h1O4B1p13594
for <sipping-emergency-web-archive@ietf.org>; Sun, 23 Feb 2003 23:11: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 h1O4Arp13576
for <sipping-emergency@optimus.ietf.org>; Sun, 23 Feb 2003 23:10:53 -0500
Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20275
for <sipping-emergency@ietf.org>; Sun, 23 Feb 2003 23:02:00 -0500 (EST)
Received: from cs.columbia.edu
(5.indianapolis-19rh15rt.in.dial-access.att.net[12.85.4.5])
by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP
id <2003022404055311100ee5v4e>; Mon, 24 Feb 2003 04:05:54 +0000
Message-ID: <3E599978.8070906@cs.columbia.edu>
Date: Sun, 23 Feb 2003 23:03:04 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "James M. Polk" <jmpolk@cisco.com>
CC: sipping-emergency@ietf.org
References: <4.3.2.7.2.20030222120157.024467d0@localhost>
<3E55EA9F.FB3489BB@lmf.ericsson.se>
<4.3.2.7.2.20030217161831.047e6110@localhost>
<3E516A89.90901@cs.columbia.edu> <3E55EA9F.FB3489BB@lmf.ericsson.se>
<4.3.2.7.2.20030222120157.024467d0@localhost>
<4.3.2.7.2.20030223115500.022b4da8@localhost>
In-Reply-To: <4.3.2.7.2.20030223115500.022b4da8@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Sipping-emergency] Re: Emergency-req: 8-12
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: 8bit
Content-Transfer-Encoding: 8bit
> > 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). 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. >> 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...? 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 >> 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 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. > 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. 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 _______________________________________________ Sipping-emergency mailing list Sipping-emergency@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-emergency
- [Sipping-emergency] General Question about Scope … James M. Polk
- Re: [Sipping-emergency] General Question about Sc… Henning Schulzrinne
- Re: [Sipping-emergency] General Question about Sc… James M. Polk
- Re: [Sipping-emergency] General Question about Sc… Gonzalo Camarillo
- [Sipping-emergency] draft-schulzrinne-sipping-eme… Henning Schulzrinne
- [Sipping-emergency] Re: [Sipping-emergency] draft… James M. Polk
- [Sipping-emergency] Re: [Sipping-emergency] draft… James M. Polk
- [Sipping-emergency] Emergency-req: remarks 1-4 Henning Schulzrinne
- Re: [Sipping-emergency] Re: [Sipping-emergency] d… Henning Schulzrinne
- [Sipping-emergency] Emergency-req: 8-12 Henning Schulzrinne
- [Sipping-emergency] Emergency-req: 13- Henning Schulzrinne
- [Sipping-emergency] Re: Emergency-req: remarks 1-4 James M. Polk
- [Sipping-emergency] Re: Emergency-req: remarks 1-4 Henning Schulzrinne
- [Sipping-emergency] Re: Emergency-req: 8-12 James M. Polk
- Re: [Sipping-emergency] Re: Emergency-req: remark… James M. Polk
- [Sipping-emergency] Re: Emergency-req: 8-12 Henning Schulzrinne