[Sip] geoloc implementation (Was: SIPit 20 survey summary)

Dale.Worley@comcast.net Sun, 29 April 2007 20:21 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFto-0005Ku-1G; Sun, 29 Apr 2007 16:21:36 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiFtn-0005Kp-9n for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 16:21:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFtn-0005Kg-0F for sip@ietf.org; Sun, 29 Apr 2007 16:21:35 -0400
Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiFtl-0004M7-Q1 for sip@ietf.org; Sun, 29 Apr 2007 16:21:34 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <20070429202133013003drb2e>; Sun, 29 Apr 2007 20:21:33 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l3TKLWqi006890 for <sip@ietf.org>; Sun, 29 Apr 2007 16:21:32 -0400
Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l3TKLWQJ006886; Sun, 29 Apr 2007 16:21:32 -0400
Date: Sun, 29 Apr 2007 16:21:32 -0400
Message-Id: <200704292021.l3TKLWQJ006886@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER> (jbemmel@zonnet.nl)
References: <20070429143911.77880@gmx.net> <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu> <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER> <20070429163343.77910@gmx.net> <01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [Sip] geoloc implementation (Was: SIPit 20 survey summary)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Is this really as much of a problem as people are making out?

OK, it's *possible* that redesigning the geolocation specification
would be a good thing.  But given the amount of work that has already
been done on it, and the complexity of the requirements, it would take
me a month of work straight to verify that I truly had a Better Idea.
So I am not about to suggest that.

In regard to the complexity of the solution, a UA that provides geoloc
data (once it had some) would seem to have a fairly simple task,
formatting the data into a preselected body.  Even multipart-MIME XML
is simple if one knows in advance the skeleton.

The PSAPs, of course, are stuck parsing and interpreting all possible
formats.  That's a hard job, but on the other hand, PSAPs are built by
a small number of vendors who will be highly motivated to do a good
job.  (And PSAPs are willing to pay for this.)

The difficulty in practice is "How does the UA get its geloc data?"
(Or how does an intermediate agent get the data for the UA?)  This
does not become simpler if we change the format of geoloc data.

I expect that the major barrier to implementing geoloc support has
been the instability of the geoloc specification, combined with the
fact that SIP is not yet entering the mainstream where emergency
services support is required by regulation.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip