Subject: [Ecrit] Re: Henning's comments on -phonebcp

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Dec 2007 17:18:46 -0500

Trying to catch up with ECRIT mail... Any comments refer to -02.

On Nov 19, 2007, at 9:48 AM, Rosen, Brian wrote:

>
> 1. Henning and one or two other commenter's don't like my coarse
> location (<1KM).  First of all, there is no real source for the 1  
> KM.  I
> made it up.  What you want is something with a high enough accuracy  
> that
> the call will usually route to the right PSAP when you are near a
> boundary.  It will never be 100% accurate.  I needed to supply some
> useful advice.  I picked a number.  I have modified this text slightly
> (typically <1km except when hiding location).
>

I realize that one has to pick something, so a motivation indicating  
that this is arbitrary and simply is meant to likely result in the  
correct PSAP should be sufficient.

Somebody may also object to the use of your term "accuracy" :-)

> 2. On ED-27, about the frequency of refresh, Henning asked for text
> discussing that civic location may be an indication that the device is
> not mobile.   Devices can be mobile and report civic.  WiFi devices
> reporting the location of an AP may very well report civic.  I did not
> change the text.

I think this indicates a broader terminology confusion that we run  
into occasionally. We have two classes of devices:

(1) The measured location changes when the device moves.

(2) It doesn't change.

After all, even many corded (and, even more so, DECT-style cordless)  
phones are "mobile" in the sense that they can move. DECT-style  
cordless phones can easily move beyond the typical range of an 802.11  
device, with the Panasonic Gigarange devices promising mobility all  
the way across the farm. Radio Shack used to sell spools of 100' phone  
cords... About the only non-mobile phones are the ones truly nailed to  
a wall.

But we generally distinguish between such devices and truly mobile  
devices, such as cell phones.

Thus, maybe the term "mobile" isn't sufficiently precise, at least not  
without further qualification.

>
>
> 3. Henning raised some questions about default location.  I changed  
> the
> text to refer to -framework which does discuss this.  Generally, it's
> "best you can do" and -framework uses the example of the location of a
> CMTS in a cable modem system.  I'd welcome suggestions to improve  
> this;
> it's an important area.

I think this is about as close as we can make it without going through  
every network architecture. Since this is likely to be common, adding  
WiFi access point and cellular base station may be useful.

The wording "subscriber to any unit less" seems awkward, however. I  
assume you mean "accuracy" or "resolution"?

However, I'm not sure what you mean by "appropriate" in

Default locations MUST be marked with method=Default and
    an appropriate provided-by in the PIDF-LO.

I'm guessing that this should say "whoever provided the default  
location", but it might not hurt to be explicit here.

>
>
> 4. Notwithstanding Hannes' questioning of un-initialized device text,
> Henning raised the issue at ED-44 of how an un-initialized device
> determines if local regulation requires support of emergency  
> calling.  I
> think this is a good question.  I suspect we need something returned
> from LoST that tells it.  Discussion on this point is welcome.

This goes back to our 'un-initialized' discussion in Vancouver. I  
think we agreed that this has many more facets and is beyond our  
current ability to compress into a paragraph or two.

>
>
>
> 6.  Henning added the comment "dubious" to the text "User agents and
> proxies MUST Support Session Timer [RFC4028] to guard against session
> corruption."
> I do think we should have it.  Henning, what is the "dubious" part.  I
> can downgrade "guard against" to something milder if you are pointing
> out that session timers won't reliably determine session  
> corruption.  I
> can change corruption to some other term.
>

Session corruption isn't defined, so I'm not quite sure what threat  
you are protecting against. The only threat I know of that session  
timer addresses is that a phone will stay off-hook forever. That's not  
really a problem in our case, where the PSAP can terminate a call at  
any time. In my personal opinion, 4028 adds significant complexity  
without concomitant benefits; as far as I know, it has seen only very  
modest deployment. Requiring it requires significant changes in SIP  
libraries, so we shouldn't do this lightly.

> 7. I'd ask Henning to expand on the "confusing" comment on ED-64 and  
> the
> "don't understand" comment on ED-68.  On the latter, the prior
> requirement is disabling of features on call backs.  ED-68 is how you
> determine a call back, which I propose is simply a call from the same
> domain as the PSAP that answered the original emergency call.

I just find the wording hard to follow. Plus, the SHOULD seems  
inappropriate here - no guidance is given to the implementor how to  
handle this rather special case and when to ignore the advice.

I think you're trying to handle the case when a PSAP calls while the  
caller is in another emergency call. After all, the caller has no way  
to distinguish whether call signaling was lost or not. Also, "same  
domain" comparisons are underspecified. Do you mean that the whole  
domain has to be the same? The one in the From header? The Contact  
header?

Also, if not done carefully, this has significant denial-of-service  
opportunities if somebody manages to fake the relevant header field.

This requires further discussion, probably as a separate thread.

Also, for ED-63, I don't know what "when answered" means. I'm guessing  
that this means that

The device should alert the user and re-connect the user to the same  
URL when the user picks up.

>
>
> 8.  I'd also like a little more information on the "check spec"  
> comment
> on ED-76.  Which spec am I checking for what?

This was a note to myself...

The problem is that the service URN draft does not have a ;test  
parameter. Indeed, it doesn't have any semicolon-parameters at all.  
Thus, the mechanism proposed does not work.

There are two alternatives that come to mind immediately:

- Define a 'test' request URI parameter that's valid for all SIP  
request URIs. This presumably requires a new draft.

- Define a sub-service for each service, as in

urn:service:sos.police.test

This has the advantage that LoST can easily return a special URL just  
for testing, to keep test calls out of the PSAP. The default behavior  
for LoST would return the URL for urn:service:sos.police if there's no  
separate test URL.

A third alternative is to define such a parameter for the service URN.  
Given the AUTH48 state of the document, this might require an  
emergency brake.

> Brian
> <winmail.dat>

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 28 Dec 2007 20:31:38 -0600

A few comments inline.

> > (typically <1km except when hiding location).

[AJW] This actually misses the point. The point is that location used
for determining a route to a local PSAP MUST be sufficiently precise to
minimize/eliminate call misrouting. This has nothing to do with location
hiding, it is to do with route determination. In many cases, Australia
is just one, indication of country is sufficiently good for routing.

>     an appropriate provided-by in the PIDF-LO.

[AJW] There is no such thing as default method, at least at the moment.
Values for method need to be defined in the IANA registry. If you want
to register a value of default, I would request that you clearly
indicate what it means, because it isn't at all clear to me what it
means.

> current ability to compress into a paragraph or two.

[AJW] I totally agree with Henning on this point.

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