Subject: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 50

From: Andres Kütt <[email-masked]>
Date: Fri, 20 Apr 2007 14:22:49 -0700

Yes,

    As long as other flows (an AP knowing exactly where it is and
broadcasting that information) are possible, the suggestion makes sense.

Yours,
Andres

On 4/20/07 7:36 AM, "[email-masked]" <[email-masked]> wrote:

> Send Ecrit mailing list submissions to
> [email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/ecrit
> or, via email, send a message with subject or body 'help' to
> [email-masked]
> 
> You can reach the person managing the list at
> [email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ecrit digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re: [Geopriv] Soliciting Feedback: (Partial)
>       LocationHiding Emergency Services Architecture (Henning Schulzrinne)
>    2. Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
>       doendpoint centric LCP without giving away the store
>       (Henning Schulzrinne)
>    3. Consensus Call: Precise Location Information not available to
>       End Host (Hannes Tschofenig)
>    4. AW: [Ecrit] Consensus Call: Precise Location Information not
>       available to End Host (Liess, Laura)
>    5. RE: Consensus Call: Precise Location Information notavailable
>       to End Host (Brian Rosen)
>    6. Please remove my name -UNSUBSCRIBE (Beyer, Loraine)
>    7. RE: Re: [Geopriv] Soliciting Feedback:
>       (Partial)LocationHiding Emergency Services Architecture
>       (Stark, Barbara)
>    8. AW: [Ecrit] Consensus Call: Precise Location Information
>       notavailable to End Host (Liess, Laura)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 19 Apr 2007 19:42:12 -0400
> From: Henning Schulzrinne <[email-masked]>
> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)
> LocationHiding Emergency Services Architecture
> To: Ted Hardie <[email-masked]>
> Cc: 'ECRIT' <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
>> 
> 
> Based on my experience, there are two kinds of test calls:
> 
> - automatic: done to verify NAT operation, LoST lookups and such;
> nothing is reported unless there's a problem; done fairly regularly
> when network conditions change; no human interaction.
> 
> - manual: explicitly invoked by the user; for example, done when
> moving into a new house. There is no ringback or anything else - the
> user picks up the phone, clicks on the "test emergency call" link and
> gets information back, similar to the test numbers that regular phone
> service has (including such  numbers as 1 700 555.4141 [http://
> www.cs.columbia.edu/~hgs/internet/telephone.html]).
> 
> For example, when we installed our new departmental PBX, we wanted to
> make sure 911 worked and delivered the right number and location to
> the PSAP. We had to call the "real" 911, which our sys admin did with
> great trepidation.
> 
> 
>> Do you believe, then, that the user has to be aware of the test
>> call, and responsive
>> during it?  That's very different from the way the BCP seems to be
>> written now,
>> and I suspect there are some pretty scaly dragons there.  If, at a
>> random interval,
>> the phone rings and reports on the status of a pseudo-911 call, I
>> think users
>> are going to be surprised and may be alarmed.  I'd rather leave it
>> as something
>> where the phone confirms that the test works and stores the
>> outcome, so that a
>> user may review it and make corrections if needed.  But that means
>> storing
>> time and date along with the test call info (imagine someone saying,
>> "I'm at 3 Wall Street, and this thing believes I'm at JFK" where it
>> really meant
>> that the most recent test call was when the user was at the airport).
>> 
>> 
>> I think we should assume that the typical test call will be
>> unattended.  How
>> far off the consensus am I on that?
>> 
> 
> See above; we need both.
> 
>>> Thus, I believe that this mechanism adds significantly to the
>>> overall reliability of the system and we should encourage that it
>>> be provided, whether as location-conveyance, audio or just a PIDF-
>>> LO attachment in the 200 OK. (This generally won't work well,
>>> given the difficulty real phones have with multipart, but that's a
>>> different topic.)
>> 
>> I think incorporating it into the response to the 200 OK is the
>> best way forward,
>> and that making it part of the text actually relieves some of the
>> location hiding
>> concerns (since the information would need to be scraped from there
>> into other
>> applications).
> 
> I don't know what you have in mind. I'm sure you are not proposing to
> put it as
> 
> 200 OK (123 Main Street)
> 
> Putting it in plain text as a body (text/plain) isn't likely to deter
> scraping unless it is so obfuscated that it confuses humans, too.
> Plus, you lose the ability to know which elements are actually
> populated, so that a correct-looking address is actually unusable for
> routing or dispatch. For example, showing
> 
> Room 123 456 Corporate Plaza
> Anytown CA 01234
> 
> can still have "Room 123" show up in the street address field in PIDF-
> LO, even though the text "looks" ok.
> 
> Plus, text isn't too useful for an ATA (terminal adapter) device. It
> can't show the text, since it has no display.
> 
> Henning
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 19 Apr 2007 20:04:27 -0400
> From: Henning Schulzrinne <[email-masked]>
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
> doendpoint centric LCP without giving away the store
> To: "Dawson, Martin" <[email-masked]>
> Cc: GEOPRIV <[email-masked]>, ECRIT <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
> 
> On Apr 19, 2007, at 6:17 PM, Dawson, Martin wrote:
> 
>> OK I see...
>> 
>> If we're talking about VSPs (which I didn't think were necessary for
>> ECRIT) then I agree. However, that's the same challenge that i2 has -
>> except it's not just a routing question, it has to go to the right VPC
>> so the PSAP can get the location information from it out of band.
> 
> As per our definitions, VSPs could be something like a corporation or
> university campus, not necessarily an operator such as SunRocket,
> Verizon or Vonage. As noted before, a LoST server could also be
> operated by an independent party, just like STUN servers are today
> (e.g., http://www.stunserver.org/).
> 
> 
> 
> 
>> 
>> If this is the only scenario we are talking about, then I still think
>> there are less convoluted solutions from the perspective of the
>> device.
>> 
>> How about the "resolver" does a dereference and the LIS, realizing
>> it's
>> not an authorized requestor, just returns a country code. Or there may
> 
> That's roughly what happens in the proposal, except that the query is
> done by the UA. But that doesn't solve the problem of finding the
> right PSAP and doesn't seem to change the problems leading to the
> currently-proposed solution.
> 
>> actually be standard HTTP (for example) error constructs that would
>> provide the equivalent information. Or, as I tentatively suggested, a
>> convention for the URL construction could indicate the jurisdiction
>> - or
>> the LIS request could include a URL and a bare bones PIDF-LO (both of
>> which eliminate the additional transaction altogether). I don't think
>> any of those proposals require changes to existing specifications
>> either
>> (apart from LoST doing the dereference).
> 
> My general perception is that encoding information into URLs (not
> URNs) is considered a hack, as they are supposed to be opaque to the
> HTTP client.
> 
> 
> 
>> 
>> Anyway, my response stands. I could live with the solution but it
>> feels
>> unnecessarily convoluted.
> 
>> 
>> Cheers,
>> Martin
>> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 20 Apr 2007 10:50:01 +0200
> From: Hannes Tschofenig <[email-masked]>
> Subject: [Ecrit] Consensus Call: Precise Location Information not
> available to End Host
> To: ECRIT <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi all, 
> 
> let me try it again (I got it wrong in my previous mail).
> 
> Henning and Brian suggested an approach that
> * works nicely with the emergency services architecture we
> investigated over the past few years, and
> * addresses the case where a network operator
> does not want to disclose precise location information.
> 
> Here is the procedure:
> 
> 1. The endpoint uses an LCP to request location.  The LIS returns an LbyR
> 2. The endpoint dereferences the LbyR.
> 3. The LIS, noticing that the dereference request is from the endpoint (or
> at least not from any entity that is entitled to get fine grained location),
> takes the fine grained location and uses LoST to determine the PSAP that
> serves that location.
> 4. The LIS returns to the endpoint a location which, if submitted to LoST,
> would return the same PSAP URI the fine grained location would.  In some
> circumstances, this could be a civic with only a country.  An alternative
> that works for all circumstances is to return the polygon that defines the
> service boundary of the PSAP (which LoST can return).  Is essential that the
> PSAP URI returned from a LoST query with whatever the LIS gives the endpoint
> would be the same PSAP URI any querier using the fine grained location would
> get.
> 5. The endpoint uses the (coarse) location value it obtains to query LoST.
> It gets the (correct) PSAP URI
> 6. This is repeated at call time.  The endpoint has a valid LbyR and a valid
> PSAP URI, which it uses to construct the emergency call
> 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences
> it.  The result will be the same (coarse) location the endpoint got.  The
> VSP does a LoST query with that location, and should get the same PSAP URI
> that is in the Request URI on the call.  This validation works for coarse or
> fine validation, and of course works for LbyV without the dereference step.
> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.  It
> dereferences the LbyR but gets the fine grained location; the LIS must have
> a relationship with the ESRP/PSAP to assure this.
> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained
> location.
> 
> QUESTION: Is this approach acceptable for you?
> 
> Ciao
> Hannes
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 20 Apr 2007 12:31:54 +0200
> From: "Liess, Laura" <[email-masked]>
> Subject: AW: [Ecrit] Consensus Call: Precise Location Information not
> available to End Host
> To: <[email-masked]>,    <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
>  
> Hi,
> 
>> Here is the procedure:
>> 
>> 1. The endpoint uses an LCP to request location.  The LIS
>> returns an LbyR 2. The endpoint dereferences the LbyR.
>> 3. The LIS, noticing that the dereference request is from the
>> endpoint (or at least not from any entity that is entitled to
>> get fine grained location), takes the fine grained location
>> and uses LoST to determine the PSAP that serves that
>> location. 4. The LIS returns to the endpoint a location
>> which, if submitted to LoST, would return the the same PSAP URI
>> the fine grained location would or . In some circumstances, this
>> could be a civic with only a country.  An alternative that
>> works for all circumstances is to return the polygon that
>> defines the service boundary of the PSAP (which LoST can
>> return).  Is essential that the PSAP URI returned from a LoST
>> query with whatever the LIS gives the endpoint would be the
>> same PSAP URI any querier using the fine grained location
>> would get. 5. The endpoint uses the (coarse) location value
>> it obtains to query LoST. It gets the (correct) PSAP URI 6.
> 
> Does this mean that if for a country the LOST directory has an entry DE
> resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt
> either a)must  resolve to the same ESRP_DE as the DE entry or b)if the
> Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST
> return for locations in Frankfurt the local PSAP_Frankfurt or c) there
> are no more fine grained entries?
> 
> Or did I miss something?
> 
> Thanks a lot
> Laura
> 
>  
> 
>> This is repeated at call time.  The endpoint has a valid LbyR
>> and a valid PSAP URI, which it uses to construct the
>> emergency call 7. A VSP wishing to validate the PSAP URI
>> takes the LbyR and dereferences it.  The result will be the
>> same (coarse) location the endpoint got.  The VSP does a LoST
>> query with that location, and should get the same PSAP URI
>> that is in the Request URI on the call.  This validation
>> works for coarse or fine validation, and of course works for
>> LbyV without the dereference step. 8. The PSAP (or ESRP)
>> which is the target of the PSAP URI gets the call.  It
>> dereferences the LbyR but gets the fine grained location; the
>> LIS must have a relationship with the ESRP/PSAP to assure
>> this. 9. Any succeeding ESRPs or PSAPs can also dereference
>> and get fine grained location.
>> 
>> QUESTION: Is this approach acceptable for you?
>> 
>> Ciao
>> Hannes
>> 
>> 
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ecrit
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 20 Apr 2007 07:44:39 -0400
> From: "Brian Rosen" <[email-masked]>
> Subject: RE: [Ecrit] Consensus Call: Precise Location Information
> notavailable to End Host
> To: "'Liess, Laura'" <[email-masked]>,
> <[email-masked]>, <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
>> Does this mean that if for a country the LOST directory has an entry DE
>> resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt
>> either a)must  resolve to the same ESRP_DE as the DE entry or b)if the
>> Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST
>> return for locations in Frankfurt the local PSAP_Frankfurt or c) there
>> are no more fine grained entries?
> 
> I'm not really sure I understand your question, but let me tell you how I
> think this will work in North America:
> 
> There will be state level ESRPs (we won't be able to have a national ESRP,
> and we probably wouldn't want one anyway).  All calls in New Jersey would go
> to the New Jersey ESRP.  The LoST entries for every location in New Jersey
> will have the New Jersey ESRP as the URI.
> 
> The New Jersey ESRP will have another service, which will only be available
> inside the Emergency Services IP Network, and thus to any ESRP or PSAP in
> New Jersey, which supplies the URI of the actual PSAP that gets the call.
> The ESRP will make a LoST query with that service to route the call onward.
> That same mechanism will be used by the PSAP to query for the responder
> agencies (police, fire, ems).  A regular LoST query to
> urn:service:sos.police would return the New Jersey ESRP.
> 
> In some areas, there will be a second level of ESRP, perhaps at the county
> level.  The state ESRP will route to the county ESRP, the county ESRP will
> route to PSAP.
> 
> This means that the LIS will effectively reveal the state the caller is in,
> but not the city, since the service boundary returned by LoST for
> urn:service:sos would be the state boundary.  Of course in a smaller
> country, you may have a country level ESRP.
> 
> Does that answer your question?  If it does not, perhaps you could explain
> what you mean more fully.
> 
> Brian
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Fri, 20 Apr 2007 07:17:42 -0500
> From: "Beyer, Loraine" <[email-masked]>
> Subject: [Ecrit] Please remove my name -UNSUBSCRIBE
> To: <[email-masked]>
> Message-ID: <6FEBBDAA0B74D34E806D366A431F36B7030F3F0C@brexc47p>
> Content-Type: text/plain; charset="us-ascii"
> 
> Loraine Beyer
> 
> 
> Thank you
> 
> *****
> 
> 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. GA621
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://www1.ietf.org/pipermail/ecrit/attachments/20070420/134d7498/attachment.
> html
> 
> ------------------------------
> 
> Message: 7
> Date: Fri, 20 Apr 2007 10:09:18 -0400
> From: "Stark, Barbara" <[email-masked]>
> Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback:
> (Partial)LocationHiding Emergency Services Architecture
> To: "Brian Rosen" <[email-masked]>, "Henning Schulzrinne"
> <[email-masked]>, "Hannes Tschofenig" <[email-masked]>
> Cc: GEOPRIV <[email-masked]>, ECRIT <[email-masked]>
> Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p>
> Content-Type: text/plain; charset="US-ASCII"
> 
> I see this as an attempt to get around the access provider's "hiding". I
> can see people using the PSAP test call now as not only a means of
> testing whether an unauthenticated phone works, but as a tool to figure
> out their location, if the access provider won't give it to them.
> 
> I'm against this recommendation. But I won't fight hard, since the
> recommendation has no teeth.
> 
> I should point out, though, that phonebcp currently only describes the
> UA doing automated testing, and not providing a user interface to
> support user-initiated testing. And support of media (above and beyond
> SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I
> did object to the recommendation that PSAPs respond with the location
> value in their SIP response, if a reference were sent in the request.
> But again, I won't argue hard. This will ultimately be a matter of local
> or national policy, independent of the IETF attempts to impact such
> policy.
> Barbara
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 4:19 PM
> To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> Cc: 'GEOPRIV'; 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback:
> (Partial)LocationHiding Emergency Services Architecture
> 
>> By the way, I think it would be helpful if the framework or phonebcp
>> would recommend that PSAPs read back location information via text-to-
> 
>> speech when test calls are being placed.
> Uh, well, in a form suitable for the media offered in the first place.
> That may be text, it may be text to sign language.
> 
> Brian
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> *****
> 
> 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. GA621
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 20 Apr 2007 16:36:46 +0200
> From: "Liess, Laura" <[email-masked]>
> Subject: AW: [Ecrit] Consensus Call: Precise Location Information
> notavailable to End Host
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> Brian,
> 
> yes, that answers my question and I am OK with this approach.
> 
> Thanks a lot
> Laura   
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Brian Rosen [mailto:[email-masked]]
>> Gesendet: Freitag, 20. April 2007 13:45
>> An: Liess, Laura; [email-masked]; [email-masked]
>> Betreff: RE: [Ecrit] Consensus Call: Precise Location
>> Information notavailable to End Host
>> 
>> 
>>> Does this mean that if for a country the LOST directory has
>> an entry 
>>> DE resolving to an ESRP_DE, more fine grained LOST entries as
>>> Frankfurt either a)must  resolve to the same ESRP_DE as the
>> DE entry 
>>> or b)if the Frankfurt entry resolves to a local
>> PSAP-_Frankfurt every
>>> ASP/ISP MUST return for locations in Frankfurt the local
>>> PSAP_Frankfurt or c) there are no more fine grained entries?
>> 
>> I'm not really sure I understand your question, but let me
>> tell you how I think this will work in North America:
>> 
>> There will be state level ESRPs (we won't be able to have a
>> national ESRP, and we probably wouldn't want one anyway).
>> All calls in New Jersey would go to the New Jersey ESRP.  The
>> LoST entries for every location in New Jersey will have the
>> New Jersey ESRP as the URI.
>> 
>> The New Jersey ESRP will have another service, which will
>> only be available inside the Emergency Services IP Network,
>> and thus to any ESRP or PSAP in New Jersey, which supplies
>> the URI of the actual PSAP that gets the call. The ESRP will
>> make a LoST query with that service to route the call onward.
>> That same mechanism will be used by the PSAP to query for the
>> responder agencies (police, fire, ems).  A regular LoST query
>> to urn:service:sos.police would return the New Jersey ESRP.
>> 
>> In some areas, there will be a second level of ESRP, perhaps
>> at the county level.  The state ESRP will route to the county
>> ESRP, the county ESRP will route to PSAP.
>> 
>> This means that the LIS will effectively reveal the state the
>> caller is in, but not the city, since the service boundary
>> returned by LoST for urn:service:sos would be the state
>> boundary.  Of course in a smaller country, you may have a
>> country level ESRP.
>> 
>> Does that answer your question?  If it does not, perhaps you
>> could explain what you mean more fully.
>> 
>> Brian
>> 
>> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> End of Ecrit Digest, Vol 27, Issue 50
> *************************************

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 21 Apr 2007 15:19:31 +0200

Hi Andres, 

Thanks for your feedback. 

You correctly understood the suggestion. The current proposal does not replace the case where networks provide detailed location information to the end host for emergency call routing.  

Ciao
Hannes

PS: From a VoIP provider, like Skype, another challenge with emergency call signaling itself is that the PSAP (and the ESRP) is likely to support only SIP and not many other protocols (but that's independent to this discussion).