Re: [sipcore] Questions on location conveyance and dereferencing

"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 13 August 2010 14:39 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ADC3A68F8 for <sipcore@core3.amsl.com>; Fri, 13 Aug 2010 07:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.75
X-Spam-Level:
X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3W4d4gYvjIE for <sipcore@core3.amsl.com>; Fri, 13 Aug 2010 07:39:14 -0700 (PDT)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 685783A6838 for <sipcore@ietf.org>; Fri, 13 Aug 2010 07:39:13 -0700 (PDT)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1165461; Fri, 13 Aug 2010 16:39:48 +0200
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 6D10D1EB82AB; Fri, 13 Aug 2010 16:39:48 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 13 Aug 2010 16:39:48 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "ext Winterbottom, James" <James.Winterbottom@andrew.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 13 Aug 2010 16:39:47 +0200
Thread-Topic: [sipcore] Questions on location conveyance and dereferencing
Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYwAAUJuAAABop6EAAHVqQAAAoHrwAAE+BsAAAt1BgA==
Message-ID: <A444A0F8084434499206E78C106220CA01C46B5792@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA01C46B4FF1@MCHP058A.global-ad.net><5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <A444A0F8084434499206E78C106220CA01C46B5547@MCHP058A.global-ad.net> <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <A444A0F8084434499206E78C106220CA01C46B559B@MCHP058A.global-ad.net> <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>, <A444A0F8084434499206E78C106220CA01C46B55B5@MCHP058A.global-ad.net> <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AC@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BE56@FIESEXC015.nsn-intra.net> <A444A0F8084434499206E78C106220CA01C46B55F1@MCHP058A.global-ad.net> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEBD@FIESEXC015.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] Questions on location conveyance and dereferencing
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 14:39:20 -0000

 

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:hannes.tschofenig@nsn.com] 
> Sent: 13 August 2010 11:41
> To: Elwell, John; ext Winterbottom, James; sipcore@ietf.org
> Subject: RE: [sipcore] Questions on location conveyance and 
> dereferencing
> 
> Hi John, 
>  
> 
> > > John,
> > >
> > > I believe you make it more complicated than it really is.
> > >
> > > We have two mechanisms in SIP Location Conveyance, namely 
> > one based on
> > > SIP and the other one based on HTTP. The two clearly 
> > provide different
> > > capabilities.
> > [JRE] I am not sure what you mean here. If I search 
> > location-conveyance for "HTTP" I don't find it.
> 
> James Polk forgot to add it for a couple of years. We managed 
> to clarify
> this aspect recently on the mailing list. 
> The next version of the draft (which will hopefully show up before the
> next IETF meeting) was promised for this month. 
[JRE] Yes, of course, I recall now that there was some clarification on the mailing list in this area.

>  
> 
> > > For emergency services I suspect that for a very, very 
> long time the
> > > different parties will agree, which one they are going to
> > > use. The fixed
> > > line operators will opt for the HTTP one and maybe the cellular
> > > operators will go for the SIP based solution. HTTP will more
> > > or less be
> > > the baseline.
> > [JRE] That in itself is an interop problem. For example, if I 
> > deploy an enterprise LIS, how do I know whether it should 
> > give out HTTP or SIP URIs to its SIP UAs for inclusion in the 
> > Geolocation header field?
> 
> In your enterprise LIS for emergency services you will most 
> likely want
> to figure out who is going to consume that reference. Quite likely the
> PSAP will consume the reference. If so, you better talk to the PSAP
> responsible for that specific area. 
[JRE] Quite so, except is it likely my VoIP service provider might also want to inspect the location, to confirm correct routing? Then depending on which SP I choose to route that particular call through, they might support different URI schemes? It seems to be a mess not having a MUST implement scheme.

> 
> > 
> > >
> > > For non-emergency services I doubt that SIP location 
> > coneyance will be
> > > used anytime in the near future. The reasons is quite simple: some
> > > players will continue to struggle with the business model.
> > > Additionally,
> > > most applications use the HTTP-based web (and not SIP). If 
> > you look at
> > > the deployment of the W3C geolocation API then you will
> > > certainly agree
> > > with me and none of the stuff we are discussing here is relevant.
> > [JRE] Yes, and even if applications use presence, they might 
> > use XMPP rather than SIMPLE.
> 
> XMPP does not provide equivalent functionality of SIP location
> conveyance. 
> So, another non-issue. 
[JRE] That was not the point I was making. I was simply saying that even applications that support presence might support XMPP rather than SIMPLE, and therefore would not want to implement RFC 3856. Instead they might prefer to use HTTP.

John