RE: [Geopriv] coming to terms on location by reference

Feel free to take the suggestion to i2.5; it's a noble cause and I'm
sure the ensuing discussion will be interesting. I believe your proposal
is eminently complex, fraught with implementation difficulties, and will
meet with considerable resistance from both VSPs and the vendors of soft
switch products. I think you'd be better off waiting for i3 where the
peer signaling relationship between the PSAP and the terminal can be
capitalized on.

In the mean time, i2 is in the process of implementation so having the
IETF not helping will only likely make the IETF not relevant to its
development which will ultimately make the ability of the IETF to
contribute to further evolution that much more difficult. A great pity.
The location reference mechanism will need to be supported, by wireless
LIS operators at least, one way or the other.

Cheers,
Martin

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Friday, 15 September 2006 10:00 PM
> To: Dawson, Martin; 'Hannes Tschofenig'
> Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> > Why is there any relevance to whether the PSAP request is initiated
by
> > the CPE automatically or by an operator clicking a button on a CPE
> > screen. It seems about as relevant as the DHCP point.
> At first blush, it seems that there is value in making a direct path
from
> the LIS to the VPC (where the VPC is the watcher), rather than looping
> through the endpoint. However, when you look at the actual use case,
I
> think there is little value. The reason is that the frequency of
update
> is
> very low, so low that any optimization seems pretty worthless.
>
> The FIRST location operation is MORE complex (the endpoint gets the
> reference from the LCP, sends it to the VPC, the VPC exchanges it for
> location with the LIS). The second operation would, if there was a
direct
> connection, be more efficient (VPC to LIS). Average them for two dips
and
> it's a wash. But 2 dips IS the usual case.
>
> They both work. There is no functionality difference except that in
the
> LbyR you need an extra interface and path.
>
> i2 is a lousy use case for LbyR
>
> >
> > And a VPC does not have a call. If you're referring to a combo proxy
and
> > VPC, then you are relying on some proprietary functionality to get
the
> > request from the VPC component supporting the E2 interface and back
to
> > the proxy component. You are throwing up your hands and saying -
well do
> > something proprietary then rather then use something eminently
suitable
> > like location by reference.
> I'm saying that every VPC I know of has the proxy. If you like,
suggest
> an
> update interface between the VPC and the proxy in the i2.5 effort,
I'll
> support that. All of the VPC interfaces are NENA developed.
>
> >
> > Now, is the service bureau proxy that you're really referring to
going
> > to establish the subscribe directly to the device itself, or is it
going
> > to have to go back via the VoIP call server? If it does it directly
to
> > the device then you've just introduced all the concerns that you had
> > over third parties being able to get location via a reference. How
is
> > the device supposed to know who this proxy is? If it goes back via
the
> > VSP call server, then you're now also asking the VSP to support
some,
> > currently unspecified, additional functionality for this update
process.
> > And what if the VSP is Skype? They also need to invent a location
query
> > protocol on top of everything else?
> I'm asking that the VPC reInvite back towards the endpoint, which
means it
> goes through the VSP (this means the VPC proxy acts as a B2BUA, but
most
> of
> them do this anyway for other reasons). The VSP does not need to
support
> anything but reInvite.
>
> >
> > You were involved in the i2 WG Brian, you know we discussed all
these
> > sorts of options and dismissed them because we were looking for the
> > minimal impact on the various participants in VoIP (in the real
world).
> > It seems somewhat disingenuous in another forum to be pushing
> > impractical solutions now that i2 is published and in the process of
> > implementation.
> Mobility was not well thought out. ALL we did is to decline to do
> anything
> that would preclude supporting mobility. The word "mobile" as used in
> this
> context appears once in the i2 document, describing one use of the V3
> interface. My solution is eminently practical.
>
> >
> > It's just occurred to me that the reference to DHCP may have been
> > somewhat Freudian. Are all of these gymnastics driven by the
prospect
> > that DHCP doesn't support a location reference mechanism?
> No, it's just that you would think using DHCP as an LCP for a mobile
> device
> is ludicrous. In this use case, it is not. You might have other use
> cases
> where it would be, but not this one.
>
> I'm happy to support a location reference mechanism for DHCP if we
decide
> that is a good thing.
>
> Brian
>

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 15 Sep 2006 09:42:52 -0500