Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 02 Mar 2008 19:54:18 +0200

This is a Last Call for comments on 
http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04

Because of the timing of the impending IETF meeting and the interactions 
with other SDOs, we are setting the call for **4 weeks**.

Please have your comments in no later than March 30.

Do remember to send a note in if you have read the document and have no 
other comments other than
"its ready to go" - we need those as much as we need "I found a problem".

Thanks!
Hannes & Marc

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 2 Mar 2008 21:29:23 +0100

Hannes,
I have read the phonebcp draft and think it is good.

I have seen one problem. 

In section 13, it says:

 ED-67/SP-37 User Agents and proxys MUST disable outgoing call
   features such as
....
o  Three Way Call 

Problem:
-----------
If users have the habit of including some kind of support for making calls
through a three-party arrangement, they will suddenly discover that this
habit is blocked in an emergency situation. That could be fatal.

Three-way calling initiated by the calling user may for example be used to
invoke relay services by people with disabilities. People with speech
impairments may invoke a speech-to-speech relay service that can support the
PSAP in understanding their way of talking. Text relay services and sign
language relay services may also be invoked in this way.
There are other ways to invoke relay services, but if a habit to invoke them
by three-way calling is established, it is important to allow it also in the
emergency situation.

Questions:
1. Have I understood the restriction right that the situation I describe
would not be allowed?
2. Why is that restriction taken in?
3. Can the restriction be deleted?
4. Relay service invocation can be done in many ways. RFC 4117 describes
some, involving three-party call control. Please make sure that the users
are not blocked from using these methods in emergency call establishment as
well as call-backs. 

The same comment is valid for section 13 in the ecrit-framework draft. So
please regard this comment valid for both drafts.

Sorry for not bringing this up earlier, I hope it will not disturb the
approval process of theese good and important drafts.

Thanks  
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Sunday, March 02, 2008 6:54 PM
To: [email-masked]
Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

Do remember to send a note in if you have read the document and have no
other comments other than "its ready to go" - we need those as much as we
need "I found a problem".

Thanks!
Hannes & Marc

__________ NOD32 2913 (20080301) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: <[email-masked]>
Date: Sun, 2 Mar 2008 22:37:09 -0600

Few comments below: 

1. The title of the document does not explicitely say that this document
is about "VoIP" emergency calls. 
Suggestion: add "VoIP" to the title (... Communications Services in
support of VoIP Emergency Calling)

2. The title of the documents says "Best Current Practice for ...",
while the document is not a collection nor a subset of the currently
used practices for emergency calling. And there is no 'current practice'
for VoIP emergency calling yet, thus a 'best current practice' of yet
nonexisting practices is confusing.
Suggestion: change the title eg to "Requirements for Communication
Services in support of VoIP Emergency Calling"
(and revise the abstract section accordingly)

3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
   Request-URI of the INVITE."
Marked by whom, the endpoints, the proxies or both? Clarify

4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5
Home dial strings MAY be recognized."
Recognized by whom? Clarify

5. "ED-10 Devices SHOULD NOT have one button emergency calling
   initiation."
While I understand that the intention is to discourage vendors to design
devices with a button dedicated only for emergency calls, current mobile
phones have the possibility of 'speed dial', when a preset dial string
(including 112 or 911) can be assigned to any button. Requirement ED-10
can be also read to ban this feature in the phone. Clarify.
I do not have a suggestion, but as today's devices do not have such a
dedicated red button any more, I see no value in this requirement, it
just creates confusion.

6. "ED-11/SP-9 All emergency services specified in
[I-D.ietf-ecrit-service-urn] MUST be recognized."
Recognized by whom? Clarify.

7. "6.1.  Types of location information

   There are several forms of location.  In IETF protocols , civic and
geospatial (geo) forms are both supported."
The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all
'IETF protocols', but they do not support location. Be more specific.

8. section 6.1
"Other forms of
   location representation must be mapped into either a geo or civic for
   use in emergency calls."
Currently most mobile network carriers use cell-id for directing the
call to the correct psap. That technique will not go away for yet a long
time. While cell-id could be mapped into either civic or geo, there is
no added value in doing so, as cell-id based routing serves the purpose
just as well as civic or geo based routing. I would suggest relaxing the
requirement, otherwise the draft will go against current practices.

9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location
   MUST have at least a coarse location capability (typically <1km
   accuracy when not location hiding) at all times for routing of
calls."
I do not understand the text in the brackets. What is location hiding
(add reference to it) and what happens when it is applied, will the req
become n/a? clarify.
Same comment for AN-9

10. same paragraph as above. "This mechanism MAY be a service provided
by the access network." It is not clear what 'this mechanism' refers to.

11. "AN-8 Access networks MAY provide network-measured location
   determination.  Wireless access network which do not support network
   measured location MUST require that all devices connected to the
   network have end-system measured location. "
What kind of wireless access networks are we talking about? Commercial,
public, private, academic or all of them? I could hardly believe that a
free public network like the google one in Mountain View (which does not
support network measured location) would have a means to restrict my
laptop's access (which does not have an end-system measured location).
Suggestion: be more specific. Say 'commercial wireless access networks'
or 'subscription based wireless access networks'. It has to be a managed
network, otherwise nothing can be enforced.

12. "ED-27/INT-20 If the device sends a DHCP INFORM message"
The text should say 'DHCPINFORM' (no space between, rfc2131).

13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow
split
   tunneling VPNs, location configuration SHOULD be attempted before
   such tunnels are established."
Add reference to 'split tunneling VPNs'(if exists). If there is no
reference, then be more explicit. Say that using an LCP while on a VPN
may result in getting the location of the vpn gateway. Avoid using
non-defined terms.

14. "ED-47 Endpoints MUST support one or more mechanisms that allow them
   to determine their public IP address.  Examples include ICE ..."
It should be STUN instead of ICE.

15. "   ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in
Call
   Forward numbers or speed dial lists."
There is no such regulatory requirement in place. Vendors comply with
regulatory requirements when it comes to emergency services. This draft
is not an amendment to any regulatory document, thus this requirement is
inappropriate. Remove it.

16. general comment: the draft seem to focus on 802.11 access networks.
The term "access point" is used all over. Access networks other than
wi-fi use terms like base station, rnc, node-b, etc. If the draft is
meant to be applicable to access networks other than wi-fi, then a more
generic term should be used instead of 'Access Point'.

- gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Hannes Tschofenig
Sent: Sunday, March 02, 2008 9:54 AM
To: [email-masked]
Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

Do remember to send a note in if you have read the document and have no
other comments other than "its ready to go" - we need those as much as
we need "I found a problem".

Thanks!
Hannes & Marc

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Mar 2008 11:45:26 -0500

I think you have the restriction wrong.

The idea is that once a 9-1-1 call is in place, you can't then add someone
else.  The PSAP can, the caller can't.

In current POTS phones, we want to disable "FLASH", but the equivalent in
more feature phones is the same.

The way I propose to handle relay is to treat relay as a "carrier" in the
sense that INVITE is forwarded to relay as the outbound proxy.  The relay,
seeing that it's an emergency call sends the call onward marked with a
request to add the relay as a third leg.  

We probably should say that.

I want the bridge that joins relay to the caller and the PSAP to be the
PSAP's bridge, not the relay's bridge. 

If a call exists between the relay and the caller it could be referred to
the PSAP, with the same request to add the relay to the call.

Brian

> Sent: Sunday, March 02, 2008 3:29 PM
> To: 'Hannes Tschofenig'; [email-masked]
> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04
> 
> Hannes,

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 4 Mar 2008 14:38:20 +0100

Brian,
I suggest that some words are added to explain why the restrictions in
section 13 are needed. I still do not understand why you want to have these
limitations. 

--
The PSAP can rarely judge what relay to invoke.
----------------------------------------------
The small trial that Omnitor performed last autumn with relay service
invocation in emergency SIP multimedia calls showed that we must not expect
the PSAP to be able to judge what relay service to involve. That must be
either automatic or user initiated.

The user would likely have a thoroughly established habit of how the relay
is invoked in outgoing calls. It would be best to not deviate from that
pattern for emergency calls. It would though be good to let more media
through between the user and the PSAP than you usually do in a relay call,
where one user usually has only a voice phone. 

This comment does not nessessarily mean that I require the restriction about
3-way calls to be deleted.
----------------------------------------------------------------------------
---------
It may be true that most relay service invocation methods will lead to the
call coming to the PSAP with two legs of the three party relay call already
on the way to be established. 
But, is it not also likely that any kind of external support may be wanted
in the call, and the user be the one who best knows how to involve that
service through a 3-way connection. I do not want to see that restriction
just be inserted because of an old habit from PSTN of not accepting
flash-hook. 

Your relay invocation model may be a bit restricting.
-----------------------------------------------------
You suggest that relay service bridges shall be inserted as outbound proxies
for the users. There may be some other outbound proxy you need to configure,
e.g. for your connectivity to the network. The user may not want that tight
relation to its favourite relay service. 99% of the calls may be with
friends that are fully capable of handling the same media and modes as the
user. So, for the occasional relay call, the user may add a service
indicator of some kind, or a number analysis is done that routes the call
properly. This discussion is wider than what is suitable for the ecrit
group, but it is ccertainly interlinked. I would be interested to sort out
some relay calling models, and think that sipping is the right group to host
such a discussion. 

This whole discussion is not only about relay services, it can be language
interpreters and other supporting services as well.

Thanks

Gunnar

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, March 03, 2008 5:45 PM
To: 'Gunnar Hellström'; 'Hannes Tschofenig'; [email-masked]
Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

Brian

> Of Gunnar Hellström
> If users have the habit of including some kind of support for making 
> calls through a three-party arrangement, they will suddenly discover 
> that this habit is blocked in an emergency situation. That could be fatal.
> 
> Three-way calling initiated by the calling user may for example be 
> used to invoke relay services by people with disabilities. People with 
> speech impairments may invoke a speech-to-speech relay service that 
> can support the PSAP in understanding their way of talking. Text relay 
> services and sign language relay services may also be invoked in this 
> way.
> There are other ways to invoke relay services, but if a habit to 
> invoke them by three-way calling is established, it is important to 
> allow it also in the emergency situation.
> 
> Questions:
> 1. Have I understood the restriction right that the situation I 
> describe would not be allowed?
> 4. Relay service invocation can be done in many ways. RFC 4117 
> describes some, involving three-party call control. Please make sure 
> that the users are not blocked from using these methods in emergency 
> call establishment as well as call-backs.
> 
> The same comment is valid for section 13 in the ecrit-framework draft. 
> So please regard this comment valid for both drafts.
> 
> Of Hannes Tschofenig
> Because of the timing of the impending IETF meeting and the 
> interactions with other SDOs, we are setting the call for **4 weeks**.
> 
> Do remember to send a note in if you have read the document and have 
> no other comments other than "its ready to go" - we need those as much 
> as we need "I found a problem".
> 
> Thanks!
> Hannes & Marc
> 

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Mar 2008 14:21:25 -0600

Gabor

That this document is from the IETF means it involves IP.

more in-line below

>support of VoIP Emergency Calling)

Calls are not limited to "voice", even though each are called "calls".

>(and revise the abstract section accordingly)

While I agree there are no current practices, this document is an 
effort with a fair degree of interworking amongst emergency calling 
consortia - and the goal here is to establish an singular 
architecture, not one of many choices - therefore stating clearly 
this is "one" practice to be implemented is best. The title does 
this.  The document status is to be Proposed Standard, not Best 
Current Practice.

>Marked by whom, the endpoints, the proxies or both? Clarify

this is in the document

>Recognized by whom? Clarify

What is this document about?  (hint: entities supporting this (to be) 
IETF standard) That's whom.

>can be also read to ban this feature in the phone. Clarify.

Have you not been involved in the emergency calling discussions over 
the past several years within the IETF or NENA?

This "emergency button" was tried and if failed miserably within the 
US in the late 80s - because of too many false emergency calls 
because the single button was accidently hit (for example, in a 
lady's purse).  This wrecked havoc on PSAP call takers and first 
responders. So while this idea sounds great, it doesn't work in practice.

If this still needs to be clarified, this can be with a single sentence.

>dedicated red button any more, I see no value in this requirement, it

it clarifies that one shouldn't ever be thought of again

>Recognized by whom? Clarify.

(hint: entities supporting this (to be) IETF standard) That's whom.

>'IETF protocols', but they do not support location. Be more specific.

In these are to carry location  - I think they should consider what's 
said in this document.

To be more specific means to list every protocol that cannot support 
location and every protocol that might be able to support 
location.  The remainder either is going to or does support location.

>call to the correct psap.

Is cell-id a location?  If true, is an ALI a location. Both are 
ids... what's the difference?

>That technique will not go away for yet a long
>just as well as civic or geo based routing.

Cell-id routing... on IP?  I believe you're mixing technologies where 
mixing shouldn't be done.

>I would suggest relaxing the

...of cellular world infrastructures, which aren't IP based, so 
there's no reason this requirement addresses the legacy 
infrastructure. BTW -- I believe IMS (which is cellular based 
systems) is using PIDF-LO and location-URI references, not cell-ids

>(add reference to it) and what happens when it is applied, will the req

I agree location hiding shouldn't be in this document

>may result in getting the location of the vpn gateway. Avoid using

I agree with this

>It should be STUN instead of ICE.

I believe this is true too

>inappropriate. Remove it.

ah, so here's the issue.  I you dial 911 from a US phone and the call 
ends too early, and the call-taker chooses to call-back to the phone 
you called from, and the phone call-forwards all calls to another 
phone/location -- you're pretty much jacked.

Besides, there is text stating that where local regulation/laws 
overwrite what's written in this doc, local regulation/laws win.

>generic term should be used instead of 'Access Point'.

If this doc doesn't make it clear that

         Access Point = AP = wifi = 802.11 base-station

then this does need to be clarified. I don't remember if it does at the moment.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Mar 2008 14:32:11 -0600

Subha

Hey - I'm pretty sure this TBD isn't the same element, which means 
this guy is going ot come after us each time he thinks of a new 
element.  I agree with your analysis, though I don't want to have to 
bring several up to speed if they want to join.  I don't know if you 
can suggest that only a few of us tackle this as the EAB-location 
group, and let it stand as we work it out along the way.  If so, this 
would be better coming from both you and Allan than from me (during 
the call Friday).

James

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 13:04:02 -0600

James: some comments inline 
- gabor

-----Original Message-----
From: ext James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2008 12:21 PM
To: Bajko Gabor (Nokia-OCTO/MtView); [email-masked];
[email-masked]

Gabor

more in-line below

At 10:37 PM 3/2/2008, [email-masked] wrote:
>Few comments below:
>
>1. The title of the document does not explicitely say that this 
>document is about "VoIP" emergency calls.

<Gabor> fair enough, but adding 'IP' (... Communications Services in
support of IP based Emergency Calling) would still be beneficial.

>(and revise the abstract section accordingly)

While I agree there are no current practices, this document is an effort
with a fair degree of interworking amongst emergency calling consortia -
and the goal here is to establish an singular architecture, not one of
many choices - therefore stating clearly this is "one" practice to be
implemented is best. The title does this.  The document status is to be
Proposed Standard, not Best Current Practice.

<Gabor> the goal to establish a singular architecture and the
interworking effort happens in multiple WGs in ietf and other SDOs, not
(only) in this draft. This is clearly a requirements document and the
title should say that instead of bcp. Do we disagree on whether this is
a requirements document or not?

<Gabor> a requirement should state who should do what. Requirements
ED-4, ED-5, ED-6 and ED-11 only say what needs to be done, but not who
needs to do it. The other requirements do state both who and what, why
are these requirements special? I did not ask to reformulate because I
did not understand it, but we are not writing the document for
ourselves.

<Gabor> cell-id is not a technology. What is different between cell-id
based routing and coordinates based routing? Is IP routing based on
coordinates? No. You need a database to map sg to sg. And one of the sgs
can be the call-id.

<Gabor> cellular is not IP based? Nooo, it is as IP based as an AP
(assuming we talk about the same thing: cellular=commercial mobile
network)
You can initiate VoIP calls and it is just a matter of regulatory work
to be able to initiate VoIP emergency calls from cellular networks.
Cell-id is an identifier of a geographical area which is mapped to psap
already in today's databases. If you'll make an IP based emergency call
on cellular, that will use now and for many years to come the cell-id to
select the psap where to direct your call. It works, it's proven. I hope
we can keep the discussion technical and not become too religious about
the usability of cell-id.

<Gabor> I didn't get how your reasoning relates to the requirement.
ED-68 is about using emergency dialstrings in speed dial lists. Mobile
phones have that feature today, and there is no regulatory requirement
foreseen to ban that. 
The feature is a UI feature, not a protocol. This document should
certainly not make restrictions on what UI features vendors can
implement. If restriction will be required, those will be made by the
regulators.
And note, laws/regulation say what is not permitted and they are not
explicitely listing the allowed features, thus there is no such thing as
"regulation/laws overwrite what's written in this doc". 

then this does need to be clarified. I don't remember if it does at the
moment.

>Because of the timing of the impending IETF meeting and the
interactions

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Mar 2008 13:29:02 -0600

At 01:04 PM 3/5/2008, [email-masked] wrote:
>select the psap where to direct your call. GAbor

let's discuss this topic as its own thread.

All (not just some or one) of the following questions need to be 
answered positively and definitively in order for your Cell-id 
scenario to work in IP.

Where is the Cell-id to PSAP URI mapping done?

What database has this information?

What IP protocol is used to resolve this mapping of Cell-id to 
(appropriate) PSAP?

Where is this IP-based server located?

How can LoST be used to discover this?

What LCP will give this Cell-id to a phone to include in a SIP message?

What SIP header is this information placed in?

What form does this Cell-id have in the SIP header from the previous question?

What IETF document(s) specifies this header and Cell-id form?

  James

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Mar 2008 14:52:34 -0500

The basic agreement we have made, in NENA, is that the operator will agree
with the PSAP on a location for the cellid.  This could be a point or a
polygon.  That location will be reported, in PIDF-LO form, from the LIS.
There was a discussion about actually allowing a cell-id as an alternate
form of location representation, but it was decided not to do that.  A LIS
could, of course, construct a location reference of the form
sip:<cell-id>@opco.net, and send that.  When dereferenced, it would return
the agreed-upon location.

Brian

> James M. Polk
> Sent: Wednesday, March 05, 2008 2:29 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 5 Mar 2008 15:50:25 -0500

Of course there is no reason the operator couldn't provide civic location
(123 Main St.) in place of cell-id either (verses a geo location).  The main
objective is to have location information in the device such that it makes
sense to the consumer vs. every context having their own location
descriptions (cell-id, water meter number, telephone pole id, property tax
plat number, fire hydrant inventory id, msag address, etc.).

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Wednesday, March 05, 2008 2:53 PM
> To: 'James M. Polk'; [email-masked]; 
> [email-masked]; [email-masked]
> The basic agreement we have made, in NENA, is that the 
> operator will agree with the PSAP on a location for the 
> cellid.  This could be a point or a polygon.  That location 
> will be reported, in PIDF-LO form, from the LIS.
> There was a discussion about actually allowing a cell-id as 
> an alternate form of location representation, but it was 
> decided not to do that.  A LIS could, of course, construct a 
> location reference of the form sip:<cell-id>@opco.net, and 
> send that.  When dereferenced, it would return the 
> agreed-upon location.
> 
> Brian
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of James M. Polk
> > >Cell-id is an identifier of a geographical area which is mapped to 
> > >psap already in today's databases. If you'll make an IP based 
> > >emergency call on cellular, that will use now and for many 
> years to 
> > >come the cell-id to select the psap where to direct your 
> call. GAbor
> > 
> > What form does this Cell-id have in the SIP header from the 
> previous 
> > question?
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Mar 2008 16:01:22 -0500

Certainly.  You can return a civic as the location of the cell.  They do
that in many cases now.

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2008 3:50 PM
> To: 'Brian Rosen'; [email-masked]; [email-masked]
> Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 5 Mar 2008 15:56:52 -0600

If the Cell-ID is a full 3GPP CGI, then the country and network codes
are included in the identifier. To that end a CGI is kind of URI
already.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brian Rosen
> Sent: Thursday, 6 March 2008 6:53 AM
> To: 'James M. Polk'; [email-masked]; [email-masked];
> [email-masked]
> Of
psap
> > >on cellular, that will use now and for many years to come the
cell-id
> to

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

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 16:18:36 -0600

Right. But that means relaxing the requirement "8. section 6.1
"Other forms of location representation must be mapped into either a geo
or civic for use in emergency calls" in the draft and allow other type
of location information, all those which make sense in their specific
context.

Gabor

-----Original Message-----
From: ext Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2008 12:50 PM
To: 'Brian Rosen'; Bajko Gabor (Nokia-OCTO/MtView); [email-masked]
Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

Of course there is no reason the operator couldn't provide civic
location
(123 Main St.) in place of cell-id either (verses a geo location).  The
main objective is to have location information in the device such that
it makes sense to the consumer vs. every context having their own
location descriptions (cell-id, water meter number, telephone pole id,
property tax plat number, fire hydrant inventory id, msag address,
etc.).

-Marc-

> Of Brian Rosen

> The basic agreement we have made, in NENA, is that the operator will 
> agree with the PSAP on a location for the cellid.  This could be a 
> point or a polygon.  That location will be reported, in PIDF-LO form, 
> from the LIS.
> There was a discussion about actually allowing a cell-id as an 
> alternate form of location representation, but it was decided not to 
> do that.  A LIS could, of course, construct a location reference of 
> the form sip:<cell-id>@opco.net, and send that.  When dereferenced, it

> would return the agreed-upon location.
> 
> Brian
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Mar 2008 16:42:35 -0600

>of location information, all those which make sense in their specific

I don't understand why you want anything relaxed.  The requirement 
says PIDF-LO is the only location format to be used, and that the 
<location-info> is geo or civic. This is a MUST for interoperability 
reasons.  Cell-id doesn't accomplish this.

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 5 Mar 2008 17:51:20 -0500

Gabor,

Sorry, I think there is a misunderstanding.  I meant to state that context
specific location descriptions should NOT be allowed, which lines up with
the requirement you cite.

-Marc-

> 
> Right. But that means relaxing the requirement "8. section 
> 6.1 "Other forms of location representation must be mapped 
> into either a geo or civic for use in emergency calls" in the 
> draft and allow other type of location information, all those 
> which make sense in their specific context.
> 
> Gabor
> 
> (123 Main St.) in place of cell-id either (verses a geo 
> location).  The main objective is to have location 
> information in the device such that it makes sense to the 
> consumer vs. every context having their own location 
> descriptions (cell-id, water meter number, telephone pole id, 
> property tax plat number, fire hydrant inventory id, msag 
> address, etc.).
> 
> -Marc-
> 
> [email-masked];
> 
> > [email-masked]
> operator will 
> (cell-id)

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Mar 2008 17:51:44 -0500

I assume this is just for our general knowledge, rather than part of a
proposal to change -phonebcp.   For one thing, emergency calls use sector as
well as cell site.  Generally, we don't recommend using some kind of
construction rule where the recipient is supposed to break apart the URI and
use the components.  If parameters have to be passed, we use URI parameters.

Also, I really would rather see "opaque" identifiers, but it's not all that
important in the case we're discussing.

At any rate MCC-MNC-CellId is not a URI, I don't think anyone is going to
propose that we create a URI for it, and I don't read your response as
suggesting a change in -phonebcp.

Is that correct?

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2008 4:57 PM
> To: Brian Rosen; James M. Polk; [email-masked];
> agree
> alternate

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 5 Mar 2008 17:03:18 -0600

Yup, just general knowledge.

The way in which this work, at least for GSM, is that each "sector" is
in fact provisioned as a separate cell-id, so you get that for free.

A URI by definition has to be broken apart to work out the different
parts, so I am not sure I understand what it is you are trying to say. A
particular URI type has ABNF which defines the parts and allows it to be
easily pulled apart. The MCC-MNC-LAC-CELL form of a 3GPP Cell-id is like
wise well understood in cellular circles.

Cheers
James

> Sent: Thursday, 6 March 2008 9:52 AM
> To: Winterbottom, James; 'James M. Polk'; [email-masked];
> proposal to change -phonebcp.   For one thing, emergency calls use
sector
> as
> construction rule where the recipient is supposed to break apart the
URI
> and
(cell-id)
> > > with the PSAP on a location for the cellid.  This could be a point
or
> > a
> > > polygon.  That location will be reported, in PIDF-LO form, from
the
> > LIS.
> > > form of location representation, but it was decided not to do
that.  A
> > LIS
> > > sip:<cell-id>@opco.net, and send that.  When dereferenced, it
would
> > return
(cell-id)
> > > > >already in today's databases. If you'll make an IP based
emergency
> > call
previous
> > > > What IETF document(s) specifies this header and Cell-id form?
------------------------------------------------------------------------
> > ----------------------
------------------------------------------------------------------------
> > ----------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 5 Mar 2008 19:23:40 -0500

Okay, thanks, I didn't know the sector bit.

All I meant was that we don't usually recommend something like expecting the
client to construct a URI by concatenating [email-masked], and
expecting the server to parse the userpart of the URI to extract the
components.  There isn't anything wrong with the server constructing a URI
any way it wants, even the example above, and giving it to the client for
use as long as it's not expecting the client to be able to discern the
components by parsing.  I didn't think you were proposing that.

Brian

> Sent: Wednesday, March 05, 2008 6:03 PM

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 01:06:19 -0600

The cell-id (cgi) is a global, well defined and understood in the
cellular world. There are no interoperability issues with it. If you
think otherwise, please give examples.

Pidf-lo is an object which encapsulates preexisting location information
but it does not define the format of it.

- gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext James M. Polk
Sent: Wednesday, March 05, 2008 2:43 PM
To: Bajko Gabor (Nokia-OCTO/MtView); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

At 04:18 PM 3/5/2008, [email-masked] wrote:
>Right. But that means relaxing the requirement "8. section 6.1 "Other 
>forms of location representation must be mapped into either a geo or 
>civic for use in emergency calls" in the draft and allow other type of 
>location information, all those which make sense in their specific 
>context.

I don't understand why you want anything relaxed.  The requirement says
PIDF-LO is the only location format to be used, and that the
<location-info> is geo or civic. This is a MUST for interoperability
reasons.  Cell-id doesn't accomplish this.

> > point or a polygon.  That location will be reported, in PIDF-LO 
> > form, from the LIS.

> > > >Cell-id is an identifier of a geographical area which is mapped 
> > > >to psap already in today's databases. If you'll make an IP based

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 06 Mar 2008 08:16:42 +0100

You might want to consider that cell-id information is already available in these networks today whereas using a protocol to translate cell-ids into location is not. 

-------- Original-Nachricht --------
> Datum: Wed, 5 Mar 2008 16:01:22 -0500
> Von: "Brian Rosen" <[email-masked]>
> An: "\'Marc Linsner\'" <[email-masked]>, [email-masked], [email-masked]
> Betreff: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

> > main

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 06 Mar 2008 08:20:09 +0100

There is no additional work needed from SIP Location Conveyance point of view. The 3GPP has already specified the ability to carry cell-ids in SIP. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 05 Mar 2008 16:42:35 -0600
> Von: "James M. Polk" <[email-masked]>
> An: [email-masked], [email-masked], [email-masked], [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 06 Mar 2008 08:26:21 +0100

We also discussed this topic in a face-to-face meeting between the 3GPP and the IETF in July 2006. I recall that we were not so negative about the idea of using Cell-IDs. 

Furthermore, there are two separate things to consider: 

* Cell-ID usage for LoST to obtain a PSAP URI
* Cell-ID information as information for dispatch. 

Gabor is not proposing the second approach.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 06 Mar 2008 08:31:41 +0100

Hi James, 

> answered positively and definitively in order for your Cell-id 
Anticipating what Gabor tries to say here...

> Where is the Cell-id to PSAP URI mapping done?

That information is in the LoST database. 

> What database has this information?

See above. 

> What IP protocol is used to resolve this mapping of Cell-id to 

LoST

> Where is this IP-based server located?

A LoST server could be located anywhere. 
It is easier and more robust to place a LoST server in the access or close to the access. 

> How can LoST be used to discover this?

Using the documents we wrote; you are co-author of that document 

> What LCP will give this Cell-id to a phone to include in a SIP message?

Cell-IDs are provided by the link layer. This is already done today

> What SIP header is this information placed in?

If LoST is run at the end point then the Cell-ID does not need to be carried in SIP at all. 

However, there is a 3GPP specification that carries a cell-ID already today. I would have to search for it 

> What form does this Cell-id have in the SIP header from the previous

Need to look it up. 
> What IETF document(s) specifies this header and Cell-id form?

Only 3GPP docs do at the moment. 
There may not be a need to carry them in SIP when LoST is run at the end point. 

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 15:11:46 +0200

Hi,

About carrying Cell-id information in SIP:

Hannes Tschofenig wrote:
>However, there is a 3GPP specification that carries a cell-ID 
>already today. I would have to search for it 
>
>> 

I think this is all in IETF RFC 3455
(http://tools.ietf.org/html/rfc3455). It defines a header called
P-Access-Network-Info, which can carry a Cell-id. The details can be
found in the RFC.  

Markus

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 6 Mar 2008 08:28:21 -0500

Hannes,

What pidf-lo tag gets populated with cell-id?

-Marc- 

> On Behalf Of Hannes Tschofenig
> Sent: Thursday, March 06, 2008 2:32 AM
> To: James M. Polk; [email-masked]; [email-masked]
> Subject: [Ecrit] Questions/Answers regarding Cell-IDs
> 
> Hi James, 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Mar 2008 08:59:27 -0500

Although I am very eager to get 3GPP and IETF to work on common requirements
and mechanisms for emergency calls, and in general, everything is on the
table, having had discussions on this subject in NENA, even the wireless
carriers don't think this is a good idea.  It means, among other things that
they must maintain cell-id to actual location mappings in the LoST server,
in any PSAP that could possibly handle the call (which is effectively all
PSAPs) and in any other location application.  Generally, they thought this
was a bad idea.

Cell IDs and the mapping to locations changes often enough that maintaining
this mapping in lots of environments is difficult.  The notion of using it
as a HELD or SIP reference ID addresses all situations where someone thought
it would be cool to use it.  

Unlike a civic or a geo, no one can directly use a cell-id as location; they
have to turn it in to a civic or a geo to use it.  Thus it is, by
definition, a form of location reference.  We have mechanisms to use
location references.  If you want to use it, we have the mechanisms for
that, but then the carrier has to operate the dereference mechanism.  If
they want to provide that service, they can.  In my discussions with them,
they don't want to do that.

YMMV

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, March 06, 2008 2:26 AM
> To: Brian Rosen; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)
> 
> We also discussed this topic in a face-to-face meeting between the 3GPP
> and the IETF in July 2006. I recall that we were not so negative about the
> idea of using Cell-IDs.
>

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 16:06:44 +0200

Hi,

Talking about the different scenarios how Cell-id could be used in the
IP emergency service framework, we also still have the "conventional"
way of first mapping it into geo or civic location.

The phonebcp draft currently says:

   Other forms of
   use in emergency calls.

So, how do we expect this to happen for Cell-id? One possibility I would
see is that we could extend HELD so that the HELD request could carry
Cell-id, and the HELD server could use the Cell-id in addition to IP
address to determine the location of the mobile host. (This is what
Google does already in their map application, so actually the server
doing the mapping does not even have to be associated with the access
network, although such association would probably make the mapping more
reliable.)

Would this seem like a sensible extension to HELD?

Given how ubiquitous Cell-id already is in the cellular wireless
infrastructure, I think we should actually develop protocols that allow
it to be used in at least these ways:

a) Use it as an input in LoST for mapping to PSAP URI. 
b) Use it as an input in HELD for mapping to geo/civic location.
c) Carry it within the signaling protocol for various potential usages.
I think this is already taken care by what is defined in RFC 3455,
although I suppose it would be more inline with the rest of
ECRIT/GEOPRIV work if it was actually carried within PIDF-LO in
accordance to the SIP location conveyance. 

Markus 

>On Behalf Of ext Hannes Tschofenig
>Sent: 06 March, 2008 09:26
>To: Brian Rosen; [email-masked]; Bajko Gabor 
>(Nokia-OCTO/MtView); [email-masked]
>We also discussed this topic in a face-to-face meeting between 
>the 3GPP and the IETF in July 2006. I recall that we were not 
>so negative about the idea of using Cell-IDs. 
>
>> point or a polygon.  That location will be reported, in 
>PIDF-LO form, from the LIS.
>> > >emergency call on cellular, that will use now and for 
>many years to 
>> > >come the cell-id
>> to
>> > What form does this Cell-id have in the SIP header from 
>the previous 
>> > question?
>> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Mar 2008 20:15:29 +0200

Hi Marc,

here is one possible description:

* You get a LbyR using an LbyR
(for dispatch)
* You have the cell-ID based on the link layer interaction.
(for routing to the right PSAP)

The cell-id is used for determining the PSAP URI.
The PSAP uses the LbyR to obtain the precise location from the LIS for 
dispatch.

Another possible use case is the following

End point communicates cell-id in the SIP message (according to the 3GPP 
specifications).
The proxy uses the cell-id to determine the the route towards the PSAP. 
The PSAP uses obtains an LbyR from the LIS in order to allow the PSAP to 
retrieve the precise location.

Ciao
Hannes

Marc Linsner wrote:
>>> What LCP will give this Cell-id to a phone to include in a 
>>>       
>> SIP message?
>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 6 Mar 2008 12:37:27 -0600

Hi Markus,

The framework to extend HELD in this direction has already been drined.
Please look at http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-01

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Thu 3/6/2008 8:06 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Ecrit] Cell-id in HELD and other parts of the emergency servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id))
 
Hi,

   Other forms of

Markus

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 6 Mar 2008 14:09:26 -0500

Hannes,

I thought you implied below that you could use cell-id to lookup psap uri
via LoST...??  Is there a tag in the LoST query for cell-id?

-Marc- 

> Sent: Thursday, March 06, 2008 1:15 PM
> To: Marc Linsner
> Cc: 'James M. Polk'; [email-masked]; [email-masked]
> Subject: Re: [Ecrit] Questions/Answers regarding Cell-IDs
> 
> Hi Marc,
> 
> The PSAP uses the LbyR to obtain the precise location from 
> the LIS for dispatch.
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 06 Mar 2008 14:48:07 -0500

Gabor,

If I have a cell-id, how do I figure out where that cell is?  Is there a 
well-defined mechanism for doing that over IP?  (I'm not trying to be 
rhetorical here, I just don't know.)

My concern with using cell-id as a "pointer" to location in the Internet 
context is that there may not be a way to dereference that pointer 
(i.e., obtain the location of the cell) without going outside the 
Internet, e.g., to a 3GPP non-IP interface or some other database.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Mar 2008 22:18:52 +0200

Hi Richard,

there are two cases:

1) The LoST server is somewhere close to the access. Then, the cell-ids 
are sort of local and known to the LoST server (i.e., the location of 
the cell).

2) Some companies have global cell-id databases. I have some time ago 
sent a mail to the list about the approach Google is using that does not 
require any coorporation from the access provider to determine your 
rough location.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Mar 2008 15:33:23 -0500

I think we can dismiss the LoST query; LoST needs actual location (geo or
civic) to make the query work.  We went through the discussion several times
about the advisability of sending an indirect location (reference) to LoST
and have LoST translate that to geo or civic.  We decided not to do that.
So, unless there are new arguments to why LoST should do the indirect
cell-id to geo/civic dereference, I think whoever queries LoST has to do the
dereference.

In North America, at least, the LoST server will be the responsibility of
the local 9-1-1 Authority.  It can facilitate a carrier or access network
maintaining a local copy of the server, but the data comes from the 9-1-1
Authority.  For LoST to have the ability to map from cell id to geo/civic,
the 9-1-1 Authority would have to have the mappings.  The operators did not
want to provide that data.

Routing of emergency calls based on cell site/sector is a decision process:
the PSAPs and the carriers decide, for each site/sector, which PSAP gets the
call.  Today, they do that by picking a geo/civic that represents a
site/sector and routing on that.  If you want to change that, we need to do
a fair amount of work, not only protocol, but process and data flow.

Brian

> Sent: Thursday, March 06, 2008 3:19 PM
> To: Richard Barnes
> Cc: [email-masked]; [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Mar 2008 22:52:03 +0200

So, it seems that you would rather be in favor of using an LCP to obtain 
location based on the cell-ID and then todo the LoST lookup.
Theoretically this would be a nice solution.

However, can you imagine that cellular operators are going to like it to 
essentially give their cell-id to location mapping away for free?
While this information is currently available to Google and other large 
companies it did cost them a HUGE amount of money to get hold of that data.
I doubt that Google would share it with other people for free either.

So, do you see a practical problem?

Ciao
Hannes

Brian Rosen wrote:
>>>> Pidf-lo is an object which encapsulates preexisting location
>>>>         
>> information
>>     
>>>>> (123 Main St.) in place of cell-id either (verses a geo location).
>>>>>           
>> The
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 6 Mar 2008 16:02:59 -0500

What networks are we talking about?

All the ones I know that are in to location hiding either do proxy insertion
of location at an E-CSCF or hand out an opaque reference that will return
some location that routes to the correct PSAP to the endpoint, and the best
location available at the time of dereference to the PSAP.  They don't need
anything else.

What kind of networks were you thinking about?

Brian

> Sent: Thursday, March 06, 2008 3:52 PM
> To: Brian Rosen
> Cc: 'Richard Barnes'; [email-masked]; [email-masked]
> "Other
> says

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 6 Mar 2008 16:44:51 -0500

First two results in Google

http://client338.lab.telin.nl:8080/wasp/jsp/CellStats.jsp
http://www.cellspotting.com/webpages/cellspotting.html

Another selling-location-idea bites the dust :-)

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 6 Mar 2008 16:09:52 -0600

Hi Richard,

The Cell-ID is made up of 4 parts:

MCC = Mobile Country Code
MNC = Mobile Network Code (the operator)
LAC = Local Area Code
Cell = The number of the cell

So with this, it is actually possible to easily work out where the operator is at least to a national level, and who the operator is. The other components are assigned by the operator and and would need the operator to either provide this information to LoST directly, or provide an interface to a specific LoST server to query.

Given the operator sensitivity to this information being generally public, and the amount of cell-id movement that goes on, this may actually become quite impractical quite quickly.  Some operators I deal with for example have more than 400k cells in just one country.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Richard Barnes
Sent: Thu 3/6/2008 1:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)
 
Gabor,

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 6 Mar 2008 17:16:46 -0600

Extend away, but try to understand where the information is going to be
consumed.

I am not comfortable with a cell identifier escaping the access network
context.  In fact, I'd argue that a cell identifier is not a form of
location, but a parameter that can be used to derive location
information when combined with contextual information.

The carrier that puts the cell in place knows where the cell is, but it
is unreasonable to expect others to know this.  (3GPP & OMA evidently
agree: see Lr interface and the concepts of V-GMLC and V-SLP)

To extend the analogy, would you also mandate that LoST servers also
have a database of WiFi access points, WiMAX base stations, cable
network head-ends, and so forth?

One of the main reasons for having a LIS is to provide the translation
from network-specific information (cell-ID) into something more global
(lat/long, civic).  This means that services can be implemented to use
access-agnostic information.

I have no objection to someone describing its use, but to expect that a
LoST server also have a database that maps cell-ID to location is
unreasonable (such a database is necessary for dispatch, even if a
routing database also exists).  The two accepted forms for location are
geodetic and civic and these should be the only mandatory forms.
	
Cheers,
Martin

 (A question from the side-lines: for UMTS would you use the UTRAN cell
identifier, the SAI, or allow for both?)

> Of [email-masked]
> Sent: Friday, 7 March 2008 1:07 AM
> Subject: [Ecrit] Cell-id in HELD and other parts of the emergency
> servicesframework? (Was: WGLC on draft-ietf-ecrit-phonebcp-04 (cell-
> id))
> 
> Hi,
>

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Fri, 7 Mar 2008 10:07:47 +0100

> I doubt that Google would share it with other people for free either.

Another option is "crowdsourcing" of WLAN SSIDs / MAC addresses. For our
office location in Vienna, Loki (www.loki.com) returns a much more
precise location than Google's "My Location". Loki claims to use a
(proprietory) database of 23 millions access points (provided by
www.skyhookwireless.com) - i guess it's just a matter of time until some
open alternative database becomes available...

cheers

Alex

---

From: <[email-masked]>
Date: Fri, 7 Mar 2008 12:48:02 +0200

Hi Martin,

Martin Thomson wrote:
>One of the main reasons for having a LIS is to provide the 
>translation from network-specific information (cell-ID) into 
>something more global (lat/long, civic).  This means that 
>services can be implemented to use access-agnostic information.

How do you think this should be done in practice? Would the mobile host
use HELD to get its location or reference to it, as usual? How does the
mapping from the host's current IP address to one of the location
formats happen in practice? I suppose the mobile operator would have AAA
server of some sort which can keep track of which IP address is given to
which user, but I don't know the rest of the backend infra well enough
to understand how the LIS obtains the information it needs to respond to
a HELD query.

The reason I'm asking is that I'm trying to understand where the Cell-id
would fit wrt. HELD and LIS. In practice, would it be useful for the
HELD client to tell the LIS what it's Cell-id is directly, or do you
expect the backend infra to do all the necessary correlations starting
from the IP address?

Markus

>From: ext Thomson, Martin [mailto:[email-masked]] 
>Sent: 07 March, 2008 01:17
>To: Isomaki Markus (Nokia-OCTO/Espoo); 
>[email-masked]; [email-masked]; [email-masked]; 
>Bajko Gabor (Nokia-OCTO/MtView); [email-masked]
>Subject: RE: [Ecrit] Cell-id in HELD and other parts of the 
>emergency servicesframework? (Was: WGLC on 
>draft-ietf-ecrit-phonebcp-04 (cell-id))
>
>Extend away, but try to understand where the information is 
>going to be consumed.
>
>I am not comfortable with a cell identifier escaping the 
>access network context.  In fact, I'd argue that a cell 
>identifier is not a form of location, but a parameter that can 
>be used to derive location information when combined with 
>contextual information.
>
>The carrier that puts the cell in place knows where the cell 
>is, but it is unreasonable to expect others to know this.  
>(3GPP & OMA evidently
>To extend the analogy, would you also mandate that LoST 
>servers also have a database of WiFi access points, WiMAX base 
>stations, cable network head-ends, and so forth?
>
>One of the main reasons for having a LIS is to provide the 
>translation from network-specific information (cell-ID) into 
>something more global (lat/long, civic).  This means that 
>services can be implemented to use access-agnostic information.
>
>I have no objection to someone describing its use, but to 
>expect that a LoST server also have a database that maps 
>cell-ID to location is unreasonable (such a database is 
>necessary for dispatch, even if a routing database also 
>exists).  The two accepted forms for location are geodetic and 
>civic and these should be the only mandatory forms.
>	
>Cheers,
>Martin
>
> (A question from the side-lines: for UMTS would you use the 
>UTRAN cell identifier, the SAI, or allow for both?)
>
>On Behalf 
>> So, how do we expect this to happen for Cell-id? One possibility I 
>> would see is that we could extend HELD so that the HELD 
>request could 
>> carry Cell-id, and the HELD server could use the Cell-id in addition 
>> to IP address to determine the location of the mobile host. (This is 
>> what Google does already in their map application, so actually the 
>> server doing the mapping does not even have to be associated 
>with the 
>> access network, although such association would probably make the 
>> mapping
>more
>> reliable.)
>> 
>> >From: [email-masked] [mailto:[email-masked]] On 
>> >Behalf Of ext Hannes Tschofenig
>> >To: Brian Rosen; [email-masked]; Bajko Gabor (Nokia-OCTO/MtView); 
>> >[email-masked]
>> >We also discussed this topic in a face-to-face meeting between the 
>> >3GPP and the IETF in July 2006. I recall that we were not 
>so negative

---

From: <[email-masked]>
Date: Fri, 7 Mar 2008 13:34:07 +0200

Henning, Alexander,

Alexander Mayrhofer wrote:
>Another option is "crowdsourcing" of WLAN SSIDs / MAC 
>addresses. For our office location in Vienna, Loki 
>(www.loki.com) returns a much more precise location than 
>Google's "My Location". Loki claims to use a
>www.skyhookwireless.com) - i guess it's just a matter of time 
>until some open alternative database becomes available...

I have no doubt that these kind of things together with GPS in the
handsets will be the future of most if not all commercial location-based
services. This is why I'm wondering if all this access-network based LCP
stuff that we do in GEOPRIV/ECRIT will be quite irrelevant in the real
world. Perhaps we should think how to develop open standards for
accessing these type of global databases (at least reading info, but
also writing/contributing)? Or perhaps it's enough if they just publich
open web service APIs, in case they want to be open?

It's interesting, however, how these would be related to emergency
services. So, do we still need access-network provided location to
address the liability issues? Is the only way to get something like HELD
deployed that the regulator starts mandating it? I don't see any other
incentive, at least.

Markus

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Mar 2008 10:16:05 -0500

I think it's the case that most carriers will persist in believing that they
can make money from location, and will not facilitate acquisition of high
accuracy location information unless they are compensated.  There is a
regulatory imperative to provide location for emergency calls in most areas.
Cell based routing of an emergency call where the device can measure
location but the measuring mechanism is not turned on, and thus will take
time, or for some reason, no measurement is available, perhaps due to low
signal level, will persist.

You are asking a reasonable question: will operators send cell id around,
and expect some downstream device to have the cell id and need to turn it
into location?

Mobile IMS systems don't seem to need to do this: the E-CSCF can obtain
location using identifiers it has available to it.  Are there other mobile
cellular networks which:
1) Won't provide good location to endpoints for free
2) Will make cell id information available in the signaling
3) Will need some downstream element to be able to translate Cell Id to
location

I don't know of any.  Do you?

Brian

> [email-masked]
> Sent: Friday, March 07, 2008 6:34 AM
> To: [email-masked]; [email-masked];
> [email-masked]

---

From: <[email-masked]>
Date: Sun, 9 Mar 2008 17:09:56 -0500

The cell-id to psap mapping database one operator has could become the
LoST server of that operator. When an end device attaches to a cellular
network, it learns its cell-id and then it could use LoST to translate
its cell-id to the psap uri, as the operator can always translate its
own cell-id to the correct psap uri. There is no need for a global
database for this, the operator needs to keep its own database up to
date anyways, regardless of the amount of cell-id movement.
What is needed is that the operator's (currently existing) database
supports LoST and LoST carries cell-id. An extension to the latter one
could be done, but first lets fix the requirement. All the rest is just
reuse of existing staff.

- gabor

-----Original Message-----
From: ext Winterbottom, James [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 2:10 PM
To: Richard Barnes; Bajko Gabor (Nokia-OCTO/MtView)
Cc: [email-masked]
Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

Hi Richard,

So with this, it is actually possible to easily work out where the
operator is at least to a national level, and who the operator is. The
other components are assigned by the operator and and would need the
operator to either provide this information to LoST directly, or provide
an interface to a specific LoST server to query.

Given the operator sensitivity to this information being generally
public, and the amount of cell-id movement that goes on, this may
actually become quite impractical quite quickly.  Some operators I deal
with for example have more than 400k cells in just one country.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Richard Barnes
Sent: Thu 3/6/2008 1:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)
 
Gabor,

--Richard

[email-masked] wrote:
> information but it does not define the format of it.
> 
> - gabor
> 

>> civic for use in emergency calls" in the draft and allow other type 

>> main objective is to have location information in the device such 
>> that it makes sense to the consumer vs. every context having their 
>> own location descriptions (cell-id, water meter number, telephone 
>> pole id, property tax plat number, fire hydrant inventory id, msag 
>> address, etc.).
>>
>> -Marc-
>>
>>> Behalf Of Brian Rosen
>>> the form sip:<cell-id>@opco.net, and send that.  When dereferenced, 
>>> it would return the agreed-upon location.
>>>
>>> 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]

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Mar 2008 18:30:30 -0500

The mobile host could use HELD to get location.  If you consider the
fact that the host may be unaware of the specifics of its connection to
the Internet, it employs the usual methods for determining its location.

As to determining location based on IP in a cellular network, this
question has already been asked ;)  The first step is to determine
MSISDN/IMSI from the network infrastructure.  Apparently this is
expected of SUPL location platforms [1], but the method for solving the
problem is unspecified.  The options that we discovered included AAA
servers (which at the time involved proprietary methods), the GGSN
(another proprietary interface required), or the DHCP server (apparently
there are "conventions" used for filling out certain DHCP headers, and
you can use DHCP lease query now).  I'm not aware of any standard
methods, although I've not been following 3GPP that closely of late.
Alternatively, a LIS could sweep the whole thing under the carpet and
provide an IP address to a GMLC over MLP.  Of course, the GMLC would
have to use the same methods.

If the host is aware of the nature of its network access, it could
provide this information in a HELD request.  I've written an extension
to HELD that enables the use of device-provided information [2].  Cell
identifiers would be a reasonable addition to that document (right now,
I can't remember why I didn't add them in the first place), or a similar
document.  It would not be unreasonable for the LIS to have access to a
cell location database.

Cheers,
Martin

[1]
http://www.openmobilealliance.org/Technical/release_program/supl_v1_0.as
px
[2]
http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-01

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, 7 March 2008 9:48 PM
> To: Thomson, Martin; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Ecrit] Cell-id in HELD and other parts of the emergency
> >>    location representation must be mapped into either a geo or
civic
> >> for
(cell-id)
> >> >> alternate form of location representation, but it was decided
not
> >> >> > From: [email-masked] [mailto:[email-masked]]
On
> >> >> > Behalf
> (cell-
> >> id)

---

From: Richard Barnes <[email-masked]>
Date: Sun, 09 Mar 2008 23:58:53 -0400

Gabor,

I still don't understand how all these entities find each other.  If 
I've got a cell-id, how do I figure out which LoST server to send it to? 
  Notionally, I suppose the MNC identifies the operator, which could 
lead me to it, but you would need some mechanism for this.

My point is that the cell-id is neither a location datum (by value) nor 
a location reference in the sense in which these terms have been 
previously used.  It is not a location value because it does not 
directly represent a physical position (via public information such as a 
Coordinate Reference System).  It is not a location reference because 
there is no single protocol that can be used to obtain the location to 
which it refers (just a set of proprietary database queries).

So before cell-ids can be used to represent location, they need to be 
tied to some uniform protocol mechanism that authorized parties can use 
to obtain the associated location information.

--RB

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 10 Mar 2008 09:50:45 -0400

Gabor,

1) There is no guarantee the end host will use the cell operator's LoST
service (even if known).  The end host may use a LoST service associated
with it's VoIP provider or Aor domain provider.

2) If in fact the operator maintains a db of cell-id to psap uri, would it
not be easier to maintain a db of cell-id to common-use location then simply
advise the end host of the common-use location?  (cell-id 123 = 0000 N. Main
St.)

-Marc-

> 
> The cell-id to psap mapping database one operator has could 
> become the LoST server of that operator. When an end device 
> attaches to a cellular network, it learns its cell-id and 
> then it could use LoST to translate its cell-id to the psap 
> uri, as the operator can always translate its own cell-id to 
> the correct psap uri. There is no need for a global database 
> for this, the operator needs to keep its own database up to 
> What is needed is that the operator's (currently existing) 
> database supports LoST and LoST carries cell-id. An extension 
> to the latter one could be done, but first lets fix the 
> requirement. All the rest is just reuse of existing staff.
> 
> - gabor
> 
> 
> MNC = Mobile Network Code (the operator) LAC = Local Area 
> Code Cell = The number of the cell
> 
> So with this, it is actually possible to easily work out 
> where the operator is at least to a national level, and who 
> the operator is. The other components are assigned by the 
> operator and and would need the operator to either provide 
> this information to LoST directly, or provide an interface to 
> a specific LoST server to query.
> 
> Given the operator sensitivity to this information being 
> generally public, and the amount of cell-id movement that 
> goes on, this may actually become quite impractical quite 
> quickly.  Some operators I deal with for example have more 
> than 400k cells in just one country.
> 
> Cheers
> James
> 
> 
> 
> If I have a cell-id, how do I figure out where that cell is?  
> Is there a well-defined mechanism for doing that over IP?  
> (I'm not trying to be rhetorical here, I just don't know.)
> 
> My concern with using cell-id as a "pointer" to location in 
> the Internet context is that there may not be a way to 
> dereference that pointer (i.e., obtain the location of the 
> cell) without going outside the Internet, e.g., to a 3GPP 
> non-IP interface or some other database.
> 
> --Richard
> 
> 
> 
> 
> 
> 6.1 "Other
> location).

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Mar 2008 09:28:57 -0500

I know for a fact that quite a number of operators (not in the US) will
not provide a public cell-id to location DB or make that data generally
available. They view providing it, rightly or wrongly, as a security
risk, so a solution that was dependent on this method would certainly
not be universally deployable.

Cheers
James

Of
> Marc Linsner
> Sent: Tuesday, 11 March 2008 12:51 AM
> advise the end host of the common-use location?  (cell-id 123 = 0000
N.
> Main
(cell-id)
(cell-id)

---

From: <[email-masked]>
Date: Mon, 10 Mar 2008 09:37:06 -0500

Hi Marc,

> 1) There is no guarantee the end host will use the cell operator's
LoST service (even if known)
It will, if the LoST server discovery mechanism will provision the
device with the operator's LoST server.

> 2) If in fact the operator maintains a db of cell-id to psap uri,
would it not be easier to maintain a db of cell-id to common-use
location
See James W. answer.

We are currently talking about cell-id usage only for emergency
services. There is no reason to use the VoIP provider's LoST server,
when you can get the required information (ie psap uri) locally from the
access provider.

- gabor

-----Original Message-----
From: ext Marc Linsner [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 6:51 AM
To: Bajko Gabor (Nokia-OCTO/MtView)
Cc: [email-masked]
Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

Gabor,

2) If in fact the operator maintains a db of cell-id to psap uri, would
it not be easier to maintain a db of cell-id to common-use location then
simply advise the end host of the common-use location?  (cell-id 123 =
0000 N. Main
St.)

-Marc-

> LoST server of that operator. When an end device attaches to a 
> cellular network, it learns its cell-id and then it could use LoST to 
> translate its cell-id to the psap uri, as the operator can always 
> translate its own cell-id to the correct psap uri. There is no need 
> for a global database for this, the operator needs to keep its own 
> database up to date anyways, regardless of the amount of cell-id 
> movement.

> could be done, but first lets fix the requirement. All the rest is 
> just reuse of existing staff.
> 
> - gabor
> 
> 
> MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell = 
> The number of the cell
> 

> operator to either provide this information to LoST directly, or 
> provide an interface to a specific LoST server to query.
> 
> actually become quite impractical quite quickly.  Some operators I 
> deal with for example have more than 400k cells in just one country.
> 
> Cheers
> James
> 
> 
> 
> My concern with using cell-id as a "pointer" to location in the 
> Internet context is that there may not be a way to dereference that 
> pointer (i.e., obtain the location of the
> cell) without going outside the Internet, e.g., to a 3GPP non-IP 
> interface or some other database.
> 
> --Richard
> 
> 
> 
> 
>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 10 Mar 2008 10:40:25 -0400

James,

The cell-id to common-use location doesn't need to identify the location of
the cell tower, it only needs to provide a common-use location that lies
within the jurisdiction of the PSAP that emergency calls need to be routed
to.  The actual tower location *could* be miles away.

-Marc-

> 
> I know for a fact that quite a number of operators (not in 
> the US) will not provide a public cell-id to location DB or 
> make that data generally available. They view providing it, 
> rightly or wrongly, as a security risk, so a solution that 
> was dependent on this method would certainly not be 
> universally deployable.
> 
> Cheers
> James
>  
> 
> would it
> > not be easier to maintain a db of cell-id to common-use 
> location then 
> > 0000
> > > The cell-id to psap mapping database one operator has 
> could become 
> > > the LoST server of that operator. When an end device 
> attaches to a 
> > > cellular network, it learns its cell-id and then it could 
> use LoST 
> > > to translate its cell-id to the psap uri, as the operator 
> can always 
> > > supports LoST and LoST carries cell-id. An extension to 
> the latter 
> > > one could be done, but first lets fix the requirement. 
> All the rest 
> > > is just reuse of existing staff.
> > >
> > > - gabor
> > >
> > >
> where the 
> > > operator is at least to a national level, and who the 
> operator is. 
> > > The other components are assigned by the operator and and 
> would need 
> > > the operator to either provide this information to LoST 
> directly, or 
> generally 
> [mailto:[email-masked]] On 
> > > >>> Behalf Of Brian Rosen
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 10 Mar 2008 09:54:21 -0500

Yeah I guess that is true.
In many cases though the LAC-Cell-id component will be moot since the
MCC (country code) is good enough to identify the PSAP, and the MNC
(Network code) is good enough to identify the access provider.

So if the proposition now something like:
1) Fred enters network run by dodgey-cells inc (DCI).
2) Fred discovers LIS in DCI's network
3) Fred uses HELD (or whatever) + Cell-id + emergencyRouting to LIS
4) LIS sends back location able to provide emergencyRouting
5) Fred does LoST lookup using location, gets PSAP URI
6) Fred can make emergency calls if need be

Or are you proposing that something new needs to be done to find a local
Cell-id to PSAP location DB, and a new protocol to query the PSAP
location DC.

I guess I could see the former as Geopriv/ecrit problem. The latter
doesn't seem to make much sense to do in the IETF to me.

Cheers
James

> Sent: Tuesday, 11 March 2008 1:40 AM
> To: Winterbottom, James
> Cc: [email-masked]
> The cell-id to common-use location doesn't need to identify the
location
> of
(cell-id)
> > > > >>>> All (not just some or one) of the following questions need
to
> > be
contain

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 10 Mar 2008 11:03:27 -0400

Gabor, 

> It will, if the LoST server discovery mechanism will 
> provision the device with the operator's LoST server.

I believe that's my point, just as with any configuration data that DHCP
delivers, the host has the choice whether to use it or discard it (I don't
have to use the DNS servers that DHCP recommends).  Since the VoIP provider
is ultimately responsible for routing an emergency call, they may very well
want their clients to utilize their LoST service and configure their clients
accordingly which in turn will disregard the access provider information
and/or never run a LoST server discovery function.  Common-use location
crosses provider boundaries, proprietary location information doesn't have
the same benefit.

-Marc-

> would it not be easier to maintain a db of cell-id to 
> common-use location See James W. answer.
> 
> We are currently talking about cell-id usage only for 
> emergency services. There is no reason to use the VoIP 
> provider's LoST server, when you can get the required 
> information (ie psap uri) locally from the access provider.
> 
> - gabor
> 
> 1) There is no guarantee the end host will use the cell 
> operator's LoST service (even if known).  The end host may 
> use a LoST service associated with it's VoIP provider or Aor 
> domain provider.
> 
> 2) If in fact the operator maintains a db of cell-id to psap 
> uri, would it not be easier to maintain a db of cell-id to 
> common-use location then simply advise the end host of the 
> common-use location?  (cell-id 123 = 0000 N. Main
> St.)
> 
> -Marc-
> 
> 
> 
> 
> > 
> become the
> use LoST to 
> operator is. The
> immediately

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Mar 2008 13:29:47 -0400

This still seems to me to be a solution in search of a problem.  IMS
networks have mechanisms that don't need IETF work to allow a cell id as a
location representation.  I don't know of any networks that have this
problem.  If there are, please cite them.  If there aren't, we don't need to
keep talking about the solution.

Brian

> [email-masked]
> Sent: Monday, March 10, 2008 10:37 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Mon, 10 Mar 2008 13:09:10 -0500

The problem is there. In IMS, the UA needs to include its cell-id into
the P-Access-Network header. If it doesn't know its geolocation (which
is very probable), then there is no other location info included in the
invite. Thus, mapping is done based on the cell-id.

They will keep doing this regardless of the LoST spec. But this effort
is to harmonize between ietf and 3gpp. If usage of cell-id will be
allowed, then 3gpp would use the protocols as defined in ietf.
Otherwise, they will use it as they think fits better for their needs.

Probably I should have started with this problem statement. I just
assumed noone thinks I am sending all these mails for fun. 

- gabor

-----Original Message-----
From: ext Brian Rosen [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 10:30 AM
To: Bajko Gabor (Nokia-OCTO/MtView); [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

This still seems to me to be a solution in search of a problem.  IMS
networks have mechanisms that don't need IETF work to allow a cell id as
a location representation.  I don't know of any networks that have this
problem.  If there are, please cite them.  If there aren't, we don't
need to keep talking about the solution.

Brian

> Of [email-masked]
> location See James W. answer.
> 
> when you can get the required information (ie psap uri) locally from 
> the access provider.
> 
> - gabor
> 
> LoST service (even if known).  The end host may use a LoST service 
> associated with it's VoIP provider or Aor domain provider.
> 
> location then simply advise the end host of the common-use location?  
> (cell-id 123 = 0000 N. Main
> St.)
> 
> -Marc-
> 
> 
> 
> 
> >
> > cellular network, it learns its cell-id and then it could use LoST 
> > to translate its cell-id to the psap uri, as the operator can always

> > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell 
> > = The number of the cell
> >

> > >> that it makes sense to the consumer vs. every context having 
> > >> their own location descriptions (cell-id, water meter number, 
> > >> telephone pole id, property tax plat number, fire hydrant 
> > >> inventory id, msag address, etc.).
> > >>
> > >> -Marc-
> > >>
> > >>>> All (not just some or one) of the following questions need to 
> > >>>> be answered positively and definitively in order for your 
> > >>>> Cell-id scenario to work in IP.
> > >>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Mar 2008 14:39:12 -0400

The E-CSCF has access to the translation from cell-id to location.  That is
local to the visited network.  It queries LoST with the location and routes
the call.  It's all inside the E-CSCF (well, it could be in the RDF, but
that's another argument about whether the E-CSCF queries LoST or the E-CSCF
queries the RDF and the RDF queries LoST).

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 10, 2008 2:09 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Mar 2008 13:28:17 -0500

>P-Access-Network-Info, which can carry a Cell-id. The details can be

but this isn't used by LoST or SIP or any LCP or Presence...

Ecrit] Questions/Answers regarding Cell-IDs
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>,
	<mailto:[email-masked]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Errors-To: [email-masked]

Hannes

>That information is in the LoST database.

I don't believe it is, since you are assuming (on another thread) 
that there is an inherent proximity between the LoST server location 
and the Access provider, and I don't believe that's going to always 
be the case. The what do you do? Do you punt?

> > What database has this information?

see above - i.e., I think this won't be common

> > What IP protocol is used to resolve this mapping of Cell-id to

given:

then

how does http:mmc-mnc-lac-cell@<domain> turn into a viable LoST response?

I don't believe this is/will be true for each LoST server, where we 
are all (I believe) thinking the LoST db will be the same in each 
LoST server....

Why doesn't a LocationURI solve this without a Cell-ID, provided by the LCP?

>A LoST server could be located anywhere.

meaning there is a every-cell-tower to PSAP uri mapping maintained? By who?

>It is easier and more robust to place a LoST server in the access or 

while practical, we cannot assume that, therefore the protocols we 
use have to operate when this isn't the case.

>Using the documents we wrote; you are co-author of that document

blah

;-)

>Cell-IDs are provided by the link layer. This is already done today

fair, but the argument is being made by several of us that cell-id to 
psap-uri mapping doesn't exist anywhere.  Who will build that db and 
maintain it?  BTW - there are 100X more cell towers than PSAPs, so 
this is a large problem.

>already today. I would have to search for it

I know there is, but id doesn't get them the PSAP URI when including 
it in a SIP message.  This is what Gabor wants, and this is what many 
have voiced concerns with attempting to achieve.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Mar 2008 13:33:33 -0500

>* You get a LbyR using an LbyR

I think you mistyped

>The PSAP uses the LbyR to obtain the precise location from the LIS 
>for dispatch.

how does a SIP proxy server use a cell-id for making routing decisions?

>End point communicates cell-id in the SIP message (according to the 
>3GPP specifications).

how?

This is not going to happen in regular SIP, which is what we *have* to rely on

>The PSAP uses obtains an LbyR from the LIS in order to allow the 
>PSAP to retrieve the precise location.

If the PSAP doesn't have a locationURI, how does it ask for one from 
the LIS, and how does the PSAP know which LIS to ask to get this locationURI?

You are putting the cart before the horse here

>>>Behalf Of Hannes Tschofenig
>>>A LoST server could be located anywhere. It is easier and more 
>>>robust to place a LoST server in the access or close to the access.
>>>
>>>Only 3GPP docs do at the moment. There may not be a need to carry 
>>>them in SIP when LoST is run at the end point.
>>>Ciao
>>>Hannes
>>>
>>>
>>>>   James
>>>>
>>>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Mar 2008 17:51:10 -0500

Indeed - and I'm actually puzzled that so much bandwidth is being spent
on the specific topic of "cell-id".

* This is just one parameter for one type of network

* DSL networks have L2TP tunnel identifiers, or ATM PVC identifiers,
WiMAX networks have serving base station identifiers.

* For many networks the device doesn't even get to see these
identifiers. It's an accident of history that cellular devices see
cell-ids; it's not the basis for a generic approach to IP location.

* We actually want networks to provide a consistent query interface that
provides location so network parameters don't need to be seen in the
application space.

* Cell-ID is not actually adequate for reliable emergency call routing
in the US. That's why the CRDB exists for IS-41 networks and why
GMLC-assigned ESRK was introduced into GSM specs in 2004. Estimates of
30% misroutes based on cell-ID were the anecdotal standard prior to
that. You need to add timing measurements or other enhancements to get
decent routing.

I believe we want to rely on the access networks to provide ubiquitous
and reliable *location* determination so the clients and application
layers have a consistent basis for implementation and a consistent
experience regardless of access technology. Talking about devices
knowing they are on a cellular network, getting a cell-ID, and then LoST
knowing what to do with cell-IDs is giving me the heebee jeebies...

Let the cellular networks deal with cell-IDs so the rest of the world
doesn't have to.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Tuesday, 11 March 2008 4:30 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

need to

Brian

Of
the
LoST
would
to
> > MNC = Mobile Network Code (the operator) LAC = Local Area Code Cell
=
(cell-id)
(cell-id)
> > >> that it makes sense to the consumer vs. every context having
their
be
immediately

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Mar 2008 14:43:52 -0500

>invite. Thus, mapping is done based on the cell-id.

this is likely not going to be true. IMS operators don't like the 
idea of giving location-by-value to a UA, because they see value in 
this information, because they can change for its use.  This is why 
the *entire* locationURI discussion came about. For SPs that do not 
want to give the raw location information - that can then be used by 
competing application services providers for their purposes.  If the 
UA receives a locationURI, the IMS SP is not giving location away, 
since they can charge for its dereference.

Therefore, location will be in SIP Location Conveyance, and about no 
one (as in zero) have said they aren't going down that document's path.

>Otherwise, they will use it as they think fits better for their needs.

Are you involved in the IETF-3GPP talks that have occurred over the 
past few years?  This hasn't been a problem/obstacle in those talks 
to my knowledge (though I haven't been at every one of them)...

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 10 Mar 2008 18:16:00 -0500

From my perspective the "entire locationURI discussion" came about
because the i2 architecture needed a way for the VPC to obtain location
updates without relying on the end device. The "location hiding" aspect
emerged later. I still regard the former as the most important driver.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Tuesday, 11 March 2008 6:44 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04 (cell-id)

Behalf
> > > What is needed is that the operator's (currently existing)
database
(cell-id)
(cell-id)
On
> > > >>> point or a polygon.  That location will be reported, in
PIDF-LO

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Mar 2008 18:24:25 -0500

Martin

We can agree to disagree, and I have no problems with that on this 
one.  I just know when and why it impacted Location Conveyance (as 
that author), which is where it had to be put, and it had little - if 
anything - to do with i2.  i2 came in later to that discussion.  From 
my perspective, it was all about IMS not wanting to give location to 
UEs (i.e., UAs or the endpoint) because

#1 they didn't trust the endpoint to ever provide valid location information,
and
#2 they didn't want the endpoint to give location information to the 
endpoint to use for any other use (specifically for those uses not on 
their networks they can charge for)

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 25 Mar 2008 14:28:45 +0100

just a small additional comments on phonebcp:

SP-7 says "Proxy Servers MUST recognize emergency dial strings
represented by ..."
I assume the meaning of this requirement is "if a proxy does dial
string recognition on behalf of the client, it MUST accept dial
strings represented by ..." Otherwise it is somehow irritating since
requirement SP-2 starts with "Proxy Servers SHOULD recognize emergency
dial strings ..."

SP-24: is "at least one proxy" enough? If the first proxy does not
understand the SOS URN, the call may fail.

cheers
karl heinz

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Wed, 26 Mar 2008 08:43:42 +0100

one more thing I just noticed concerning the Request-URI: is it a MUST
or a SHOULD for the service URN? ED-4 and ED-62 differ:

   ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
   Request-URI of the INVITE.

   ED-62 The initial SIP signaling method is an INVITE request:
   1.   The Request URI SHOULD be the service URN in the "sos" tree, If
        the device cannot interpert local dial strings, the Request-URI
        SHOULD be a dial string URI [RFC4967] with the dialed digits.

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Mar 2008 09:45:45 -0400

There are two circumstances:
1. The end device does dial plan interpretation.  In that case, it puts the
Service URN.

2. The end device does not do dial plan interpretation.  In that case the
proxy does it, and puts in the Service URN.  

The result of both cases is that there is a Service URN.  That is ED-4/SP-3.
ED-62 differentiates the cases for the end device.

We could improve the text by writing a more complex ED-4/SP-3.  If that is
deemed important, I'll propose text.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karl Heinz Wolf
Sent: Wednesday, March 26, 2008 3:44 AM
To: [email-masked]
Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04

karl heinz

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 27 Mar 2008 11:16:40 +0100

>  deemed important, I'll propose text.

thank you for your explanation, Brian. So ED-4/SP-3 does not say who
marks the call, but it requires that someone (ED/SP) marks the call.

The way I understand the first part of ED-62 now is:
"the Request URI MUST be the service URN in the "sos" tree if the
device interprets dial strings. If the device cannot interpret local
dial strings, the Request-URI SHOULD be a dial string URI [RFC4967]
with the dialed digits."
Is this correct?

karl heinz