Subject: [Geopriv] HELD - Is HTTP appropriate

From: "Brian Rosen" <[email-masked]>
Date: Mon, 1 Aug 2005 09:45:42 -0400

Discussion of HELD was cut off, with a request to bring issues to the list

One issue is the discussion of whether HTTP is an appropriate protocol to
use for this purpose.

Let's assume that some L7 protocol is a good idea.  Let's also assume
PIDF-LO, which is XML, is a good format to return location.

That still begs the question: Is HTTP the right protocol?

It would seem that we have a unique use, for which we are not going to be
able to reuse a lot of existing infrastructure.  We have a fairly
straightforward request/response mechanism, and we have fairly well
understood behaviors with respect to the actual protocol.  Would it not be
better to consider alternatives?  BEEP for example?  A real web service? A
new protocol? 

HTTP gets misused for lots of things that can be made to work sort of.  This
one seems like such a misuse.  

Brian

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 5 Aug 2005 00:07:49 +1000

I can't answer some of those problems, nor would I want to put words in
someone else's mouth, but I believe that I have some insight into the
situation.  I will attempt to address some of your questions.

----
> Can you articulate why DHCP does not meet your needs?
> 

DHCP is not universally deployed.  I believe that you yourself mentioned in
your presentation in the sipping meeting that an access provider might like
to NOT provide location information to a device, I certainly know that that
statement is true.  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.

> 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.  The SIP location conveyance draft alludes to some SIP proxy
in the path inserting location information (by-reference).  This, to me,
implies that the SIP proxy must retrieve this information from somewhere,
which also then implies that the SIP proxy must request information "on
behalf of" the UA.  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.

Cheers,
Martin

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 04 Aug 2005 10:32:16 -0500

Martin

in-line

At 12:07 AM 8/5/2005 +1000, Martin Thomson wrote:

>DHCP is not universally deployed.

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....

>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.

>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.

Inserting the location by-reference in a URI is one solution 
(intermediaries cannot insert PIDF-LO message bodies unless they are B2BUAs).

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.

>I certainly know that that statement is true.

how and why is this "true"?

Is this a business decision or a liability decision?

I do not believe this is a technical decision.

>That would preclude LCI.

no it isn't.

Alice is in trouble (in the US).

Alice calls 911 (which is a SIP INVITE To sos).

         INVITE [email-masked] SIP/2.0
         Via: <pc33.atlanta.example.com>; branch=75432u29ur59432u
         To: <[email-masked]>
         From: Alice <[email-masked]>
         Max-forwards: 70
         Contact: ...
         Content-type: application/sdp
         Content-length: ...

         v=...

Alice's UA doesn't include any location by-value or location by-reference; 
either she doesn't have her location, or she doesn't know to include it in 
the first place.

         note: if she doesn't know her location, but the UA knows it is needed
         for this transaction to succeed, she includes something like this 
into
         the above INVITE message:

         Location: unknown

A SIP Proxy receives this INVITE.

What does the Proxy do with this message?

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?

>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?

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.

>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.

>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).

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.

>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?

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.

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.

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... ;-)

>Martin

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 4 Aug 2005 15:22:17 -0500

In line below...
Barbara

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Thursday, August 04, 2005 9:51 AM
To: Stark, Barbara; GEOPRIV
Subject: RE: [Geopriv] HELD - Is HTTP appropriate

At 12:04 PM 8/3/2005 -0500, Stark, Barbara wrote:

>HELD is particularly interesting, since I don't see the DHCP solution
>meeting my needs.

---------Barbara's response------------
In the context of consumer DSL customers:
1. As stated in other emails, most VoIP clients will get DHCP from
local, home routers. These would need to be upgraded both with ability
to respond to 123 option, and upgraded to get location info from the
network. 
   a) Consumers don't tend to update their home routers very often. And
they don't give a flip about FCC mandates. 
   b) How does the home router get its location info?
      -> the majority of DSL installs use PPPoE in the US; BellSouth
(the ISP) has about 2 Million DSL customers, of which probably over 99%
are PPPoE (and yes, IPCP could probably be modified, but that still
leaves other issues)
   c) Since there's no guarantee that a VoIP device will be behind a
DHCP server that can do DHCP 123 and  that knows its location, a higher
layer protocol that can query directly out to the ISP can add value.

2. The IP address that is provided to the DSL customer in most cases
comes from an ISP. The ISP is frequently not the same as the access
provider. In the world of DSL (in the US and many European countries),
the access provider frequently wholesales DSL service to many different
ISPs, and access providers often put traffic through an aggregator
before before sending it to the ISP. This aggregator terminates
Ethernet, and sends the PPP sessions of many different end customers to
the ISP across a single physical interface, on a single L2TP tunnel. The
ISP has no information in any of its systems or network elements that
can tell it the physical location of an IP address that it handed out
(other than the static billing address of the end customer). Only the
access provider has this information (but the access provider doesn't
know the IP address). In the world of HELD, I have an expectation that
HELD can also be used to let the ISP LIS query the access provider LIS
for the location. I need some way for the different companies to talk to
each other, and need for that way to be standard. Otherwise, nationwide
ISPs would have to develop a different mechanism for each access
provider they use. By the way, the ISP does have enough information to
send to the access provider, to allow the access provider to respond
with the proper location. I think we can safely say that DHCP won't work
for ISP <-> access provider communications.

3. I need HELD for OBO. I'll respond to your OBO questions further down,
and hopefully explain why OBO is reasonable and why DHCP doesn't work
for OBO.
-----------------------------

>A L7 solution is exactly what I want and need,

I'm trying to understand how you have jumped to the conclusion that an
L7 
protocol is "what you want and need" if the requirements have not been 
either agreed upon and worked out. Can you explain this from your point
of 
view?
-----------Barbara's response-------
I'm not sure which requirements you're referring to. I'm seeing in all
this that there's an expectation for ISPs to be able to hand out
location info. That means there's a need for ISPs to be able to get
location info from the access provider. There's also a need for ISPs
that use IPCP to configure end customer devices, to be able to provide
location info. I also see an expectation for VoIP providers to do a
better job with 911 than what we can do today (with static addresses
that may or may not be where the service is actually being used), and I
see the need to do this before 100% of end devices are location-aware.
Independent of any requirements that an IETF WG chooses to express,
these needs and wants and expectations remain.
-------------------------------------

>both
>for getting location info to location-aware broadband routers

"location-aware broadband routers"

Can you tell me what these are to you?

In other words, is this *router* an ESRP or a DSL modem?
-------------Barbara's response-------------
A consumer-grade DSL/cable router, which may or may not have a built-in
DSL modem. Currently, BellSouth (the ISP) ships routers with built-in
DSL modems to all its DSL customers. A fair number choose to turn off
the router and DHCP functionality in this box and put their own home
router (that does the DHCP) behind it. But the vast majority of
BellSouth's (the ISP) customers now have a router (that does DHCP) in
their home. This goes back to the point that VoIP devices in homes will
generally DHCP to a home router.
--------------------------------------------

>and VoIP
>devices, and to be able to do OBO location discovery for
>location-unaware devices.

How is the location of an endpoint "discovered" if there is zero
indication 
in the SIP INVITE message that is *to* 911?

And if there is no location of the endpoint known, how is the SIP
message 
ever routed correctly?

---------Barbara's response-------------------
I'm now going to switch from my role as access provider and ISP to my
role as VoIP service provider (VSP).
As a VSP, I expect my customers to register with my registration server
(possibly indirectly through a Session/Border Controller), and to send
SIP INVITE messages to my proxy server (or Session/Border Controller).
If my customer base is largely filled with location-unaware devices (and
I'll know this, since they'll mostly use devices I provide/approve and
manage, and I know churn rates and such), then I may choose to do an OBO
lookup of their location at time of registration (but perhaps only when
the IP address changes) and store it away in case of an emergency call.
Given the low likelihood of an emergency call actually happening and the
great quantity of devices I hope to support, it might be nice if I only
had to store a reference to the location. The only info I'll have for
this lookup will be the public IP address, and I'll have to use reverse
DNS of the IP address and the "DNS Service Record" option from HELD to
locate the ISP's LIS server (assuming it has one). If the VoIP device is
currently using an ISP that uses one public IP address for many
subscribers (an early implemenentation that is rarely seen these days),
then I have a problem. Most ISPs these days hand out public IP addresses
to end customers, though, so it should be ok in most cases.
If my customer base is largely filled with location-aware devices, then
I may choose to do an OBO lookup only at time of 911/sos INVITE that
arrives without location info.
If I can't get a location dynamically, I'll probably have to use a
statically saved address for that customer, when an emergency call comes
in without a location.
I think the FCC has stated that VSPs now have to provide handling of
emergency calls on all VoIP lines they provide. If this interpretation
of the order is correct, then that means not sending the call anywhere
is not an option.

If an INVITE comes with a location, I'll use that, instead of any OBO or
static location. If I can't figure out at all where to send the call,
based on the INVITE's location (e.g., bogus/non-existant location), then
we're back to OBO and static.
------------------------------------------------ 

>I believe that the OBO functionality will be a
>great step forward

I am still attempting to figure out how it can work.

>Barbara

cheers,
James

                                 *******************

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163