Subject: RE: [Geopriv] HELD - Is HTTP appropriate

From: "Martin Thomson" <[email-masked]>
Date: Fri, 5 Aug 2005 02:14:32 +1000

Hi James,

Thanks for the response, my answers...err, responses are in-line.

> 
> DHCP is not being promoted as a universal solution, but what 
> non-cellular 
> percentage of IP endpoints don't use DHCP?
> 
> Most Cable Internet Access uses DHCP and many very large DSL 
> providers use 
> DHCP. Nearly all enterprise networks use DHCP. But more on 
> this below....

My information indicates that it is the opposite case, most DSL providers do
not use DHCP.  That is the basis for that argument.  FYI, DHCP is not
provided on my home DSL service.

> 
> >I believe that you yourself mentioned in your presentation in the 
> >sipping
> >meeting
> 
> I didn't present in SIPPING. I did present in SIP though.

My bad.

> >that an access provider might like to NOT provide location 
> information 
> >to
> >a device,
> 
> no, the point was brought up during my discussion of the new 
> "unknown" 
> option-tag in which the UA knows the INVITE needs its 
> location but doesn't 
> have it, and is asking for help "by some intermediary" along 
> the message path.
>
Sorry, I misrepresented your document.  The point stands though, the UA
doesn't include location information (either by-value or -reference), even
if it indicates that it needs it.
 
> Inserting the location by-reference in a URI is one solution 
> (intermediaries cannot insert PIDF-LO message bodies unless 
> they are B2BUAs).

Agreed, but this has been explored here and elsewhere as a viable option.  A
B2BUA would also be another option, but that is ancillary.

> 
> The 425 (Retry Location Body) transaction can also solve this 
> (see section 
> 7 of the SIP Loc ID).
> 
> I postulated that when an IAP has not enabled the 
> functionality yet for 
> downloading location to an endpoint, the "unknown" option-tag 
> would help 
> the message succeed. I did not discuss the scenario that tha 
> IAP refuse do 
> this.

That is not what I remembered, but you said it, so I can't argue that point
:)

> 
> >I certainly know that that statement is true.
> 
> how and why is this "true"?

I talked to a service provider and they said as much.

> Is this a business decision or a liability decision?
> 
Business prerogatives were certainly a motivator, but I can't speak on
liability.

> I do not believe this is a technical decision.
> 
> >That would preclude LCI.
> >
> ><snip>
> >
> > > How is the location of an endpoint "discovered" if there is zero 
> > > indication in the SIP INVITE message that is *to* 911?
> > >
> >
> >I'm not sure that I understand what it is that you want when you ask 
> >this
> >question.  I'm sure that identifying an emergency service request is 
> >orthogonal to providing location information in that request.
> 
> no it isn't.
> 
> <snip example - all agreed - we can talk about the location header
elsewhere>
> 
> What does the Proxy do with this message?
> 
Routes it to the correct PSAP, if it can. (see below)

> Where does the Proxy route the message?
> 
> What field/fields/indication's) does the Proxy use from this 
> INVITE to send 
> to a "mapping protocol" process to determine where Alice is 
> to route the 
> INVITE to the proper PSAP?

I think that this is a question of: how is any particular call identified as
NEEDING special treatment.  In this case, the special treatment is routing
based on location and, perhaps, preferential treatment and some skipping of
certain controls.

> 
> > > And if there is no location of the endpoint known, how is the SIP 
> > > message ever routed correctly?
> >
> >That is clear, someone has to determine location and that is why the
> >concept of OBO exists.
> 
> Please tell me what in the above INVITE is used to determine the OBO 
> message flow?

That depends, based on where the first proxy is and so forth.  The same
methods that you talk about below are also applicable.  Maybe the first
proxy is able to see the source IP and request "on behalf of" that client to
a location server.  On the other hand, I don't see how a header including
"location: unknown" is going to provide any intermediary any more
information.

> What is sent (using whatever protocol) to determine where 
> Alice is? Her IP 
> address can be anywhere.  Her MAC Address doesn't tell you 
> anything. Her 
> domain doesn't tell you where she is.

All true, but within her access network, that information tells network
elements how to identify Alice.  With that identification information, the
network can then take steps to find Alice - tracing wiremaps (just like in
DHCP), or whatever is necessary for that particular access network, to
determine location information.

> >The SIP location conveyance draft alludes to some SIP proxy 
> in the path
> >inserting location information (by-reference).
> 
> First, the text currently states by-reference is a last 
> resort for several 
> reasons I still believe, although I will loosen the text up a 
> bit in the 
> next version.

I actually agree with some of those reasons, but I probably place less
significance on those.  That might just be an individual value proposition.

> >This, to me, implies that the SIP proxy must retrieve this 
> information
> >from somewhere,
> 
> the Proxy may know a sighter that can provide the location of the UAC 
> for/to the Proxy. From this information, the Proxy can insert this 
> information in a Location header (by-reference) or reject the 
> message but 
> include the PIDF-LO in that 425 message to allow the UAC to retry the 
> INVITE with the PIDF-LO in the INVITE (by-value).

Sighter?

I'm not sure how that is different again from OBO, except for the 425.

> 
> If this location mapping protocol fails, the 911 call fails. If the 
> location is by-value (included in the INVITE message, it 
> doesn't fail to 
> get to a PSAP - and chances are it's the right one the first time.

That seems logical.

> >which also then implies that the SIP proxy must request 
> information "on
> >behalf of" the UA.
> 
> "OBO" is proxying for the previous SIP hop.... this is 
> already defined in 
> SIP, so this isn't new. By this, I'm saying a SIP Proxy performs this 
> function as its primary purpose (determining a route for a 
> message the 
> previous SIP element could not itself).
> 
> This can be of a local database, btw.
> 

> 
> >Maybe we are talking cross-purposes because we have a 
> different basis 
> >for
> >understanding on this, so if you have more concerns, I would 
> be happy to 
> >elaborate on this.
> 
> If the SIP Proxy cannot determine how to route the message,  
> I want to know 
> how HELD will do this (when SIP cannot). Where's the 
> bootstrap/trigger?

HELD isn't about routing, we were talking about insertion of location
information in headers.  It doesn't actually DO that, but that is a major
reason why OBO exists - so it can help.

> But more on your previous comment on the viability of DHCP... 
> and maybe I'm 
> in a unique location (pun intended), but I have DSL service 
> from a little 
> company called SBC - that uses DHCP. I also have Cable Modem 
> service from a 
> little company called Comcast - that uses DHCP. I had at my 
> previous house 
> (pre-2000) DSL service from a little company called Verizon.
> 
As I said before, my information differs, and I would also like to point out
that the same DSL provider often provides configuration methods in different
parts of their networks.  Some of those "little" providers almost have more
customers than my country has citizens :)

> I like all 3 companies - which is why I do not mind calling 
> each out here.
> 
> My point is, all 3 different companies, using 2 of the 
> primary residential 
> Internet Access technologies, each uses DHCP. So while that is not a 
> representative example of the world, it represents a fair piece of 
> marketshare pie advocating DHCP as viable for this purpose 
> distributing IP 
> addresses (among other configuration information).  I have argued 
> "location" is now a critical piece of configuration information.

My argument takes a slightly different angle, but with the same goal
methinks.  Location is a critical service of an access network.  We can
agree on that I think.  Our approach differs, I would say that the
configuration includes instead where and how you access that service, and
not the actual location information.  It's an important layer of indirection
that is more powerful.
 
> Thus, DHCP shouldn't be eliminated as a delivery mechanism of 
> location by 
> something else that is not proven, and currently has far less than 
> universal support even within the Geopriv WG.
> 
> off my soap-baox again... ;-)
> 
> cheers,
> James
> 

Ta,
Martin
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Aug 2005 12:57:49 -0400

Just one point: In these discussions, we need to keep in mind that we want
the location of a VoIP endpoint, which in geopriv speak is the Target.
Nearly all of them get their IP address from DHCP. As I understand it, the
problem for DSL systems is that the DHCP server in many cases is a small
home router, and the question becomes, how does it get location?  In many
present day DSL systems, it is connected to a DSL modem, and you then get to
ask, how does that get location?  Neither use DHCP to get IP addresses; PPoE
is common, but not universal.

The protocol between the DSL modem and the DSL infrastructure is
"proprietary" (of course there are standards, but they are DSL specific
standards).  It can be modified any way the DSL industry wishes to modify it
to pass location.  As a practical matter, the same is true of the DSL
modem-to-home router link.  If it would help, I'm sure we can, for example,
add location to PPoE.

My understanding is that the real problem driving an L7 approach is
installed base.  If we did provide DSL modem and home router protocol
upgrades, we would have to do firmware upgrades in the field.  This is
considered to be possible in theory, but nearly impossible in practice.
Thus they want to bypass their entire infrastructure, and have the VoIP
endpoints get location from some server they would deploy, skipping the DSL
modem and the home router.  The point of the new protocol is to avoid an
upgrade of existing firmware.

To be fair, they then say, if we do it, every VoIP endpoint (and any other
endpoint for that matter) can use it.

The reason we started down the DHCP route to deliver location to the Target
is because it's LOCAL, lower in the layer stack, and we thought we would
have fewer problems, and better results, if we did so.  The domain of a DHCP
server is typically a lot smaller than the domain of a web server.  YMMV.

Brian

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Martin Thomson
Sent: Thursday, August 04, 2005 12:15 PM
To: 'James M. Polk'; GEOPRIV
Subject: RE: [Geopriv] HELD - Is HTTP appropriate

Hi James, 
My bad. 
  
elsewhere> 
Sighter? 
That seems logical. 

Ta, 
Martin