Re: [Ecrit] FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt

[Ted Hardie <hardie at qualcomm.com>]

At 8:14 AM -0800 1/6/09, Brian Rosen wrote:
>Called Party Hold is no longer universally available.

Thanks for this clarification; it would be nice if future
versions of the document noted this.


>The statement about some jurisdictions wishing to retain their current
>capability and others wishing to regain it is entirely true.


>  It is the fact
>that some carriers did not require Called Party Hold of their vendors that
>caused the loss of the feature. 

They were able to do this, presumably, because there was no regulatory
requirement here, eh?

>Wireless carriers never implemented it,
>despite the PSAPs desire for it to be implemented.  I fail to see your
>point: some jurisdictions have the capability described in the requirements
>now and wish to keep it.  Others used to have it, lost it, and want it back.
>Others don't think they need it, whether they had it or have it.

I guess I wasn't clear, sorry.  No jurisdiction has it now for all calls, because
no calls coming from wireless devices have this capabilities.  This entire
document casts this as a problem of retaining or restoring a capability.
The reality is that it is about creating a new one, because it requires
the creation of a capability in a completely different technical and social
context.   In a wireline 911 context prior to this, for example, it was darned unlikely
that the caller and PSAP were associated with networks in different jurisdictions.
But the system we've put together here allows for someone in Toronto
whose only working phone happens to tunnel back to Germany to determine
the correct PSAP for their location and make an emergency call.  How does
that phone (or that network) treat the requirements for CPH?

Those are different issues that those faced by the PSTN alone.  Trying to put
forth the requirements from only the PSAP perspective simply isn't adequate
in this context, at least in my personal opinion.

>"Alerting" is how you describe what is desired in human terms.  The human is
>alerted.  The phone "rings". 
>
>Please tell me how, on the one hand, I am asked to describe the requirements
>in human terms only, no signaling, and yet have negotiation requirements?

Perhaps by making a requirement that there is a need for agreement
here between the human user and the PSAP on who should have this
control?  Since this isn't the same in all jurisdictions, you can have
a mismatch both ways.

>My best answer is PD-7, where it describes that the PSAP controls whether
>premature disconnect control happens on a call-by-call basis and in AC-3,
>where I describe that the human may notice that abandoned call hold up
>doesn't always happen.

Can you think of putting these requirements in terms of the user,
rather than the PSAP's desires?

> I probably could improve the requirements by having
>both a "PSAP can control" and a "User may notice" in both PD and AC
>requirements, but I think the point comes across that it's an enabled, and
>negotiated feature.
>
>Did you miss this text:
>When PD-1 is enforced, the caller must not be able to place another call
>until the PSAP allows the call to be released.  This requirement is not
>intended to imply a user interface with multiple lines accessible
>independently is locked to the single line that placed the emergency call.
>As mistakes can be made, an override mechanism invoked by the caller must be
>feasible.  The implementation must fail safely such that the phone cannot be
>locked and unable to call for help.

No, I didn't miss it, but I'm apparently missing which part of my message
you're referring to here.  Sorry for being dense.

>I don't see how you could have the PSAP control the function on a call by
>call basis, and have it handled by UI alone.

You are looking at this as PSAP call control, rather than that at the base
requirement--"The user shouldn't stop talking until the call taker says
it is okay to go."  The UI *can* enforce that if it knows that this is the PSAP
expectation.  That is metadata related to the PSAP's location in your
system so far (since it is jurisdictional, rather than based on call
type).  We have ways of informing people about that already.

I am not saying that this is better than what you have in mind, but
if "Don't send Bye" is agreed to by the user and enforced by the
device based on metadata associated with the PSAP's location,
you seem to be a long way toward where you want to be. 

This is a long way of saying please stop just repeating things like this:

>  It's important to have the
>PSAP tell the device that it does or doesn't need the function.   It's
>important that the PSAP control the alerting.  It's important that the PSAP
>know the "hook state" of the call. 

and have the document describe what the humans need here.  There are
conflicts in that ("User control of the device should be absolute unless voluntarily
surrendered" is in conflict with "The PSAP call taker should always end the
call"), but we're not addressing those adequately with a document that
is, forgive me, all over the map like this one.

As I said before, I don't think this document is ready to be a working group
item.  I remain willing to review later iterations, and I believe that the
working group should continue to do so. 
				regards,
					Ted Hardie
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit