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

From: "Brian Rosen" <[email-masked]>
Date: Mon, 5 Jan 2009 10:46:57 -0500

This is the version with a user focus only on the requirements.

I ask that this be considered a work group item.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, January 05, 2009 10:45 AM
To: [email-masked]
Subject: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Requirements for handling abandoned calls and
premature disconnects in emergency calls on the Internet
	Author(s)       : B. Rosen
	Filename        :
draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
	Pages           : 6
	Date            : 2009-01-05

The -phonebcp draft currently requires endpoints to disable sending a BYE on
an emergency call.  Insufficient justification and lack of attention to the
entire problem has caused comment on that section of the document.  This
document attempts to define the problem and the requirements to controlling
disconnect on emergency calls.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosen-ecrit-premature-disconnect-r
qmts-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jan 2009 14:50:07 -0800

Before my main comments, I note that the document says:

The -phonebcp draft currently requires endpoints to disable sending a
BYE on an emergency call.  Insufficient justification and lack of
   attention to the entire problem has caused comment on that section of
   the document. 

That was ED-68, and it was removed in the current version of phonebcp.

				Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Jan 2009 15:02:00 -0800

The document says:

The PSTN has a feature
   available, "Called Party Hold" (CPH) which is used in some
   jurisdictions to meet this requirement.

It was my understanding that this feature was no longer universally
available in the PSTN, not that it was universally available and
not used in all jurisdictions.  Have I misunderstood this?

As the document notes, it is not available in wireless networks,
which are the majority of initiating networks for emergency
calls in at least some jurisdictions.  I believe that this makes
this statement:

   Some jurisdictions are
   desirous of maintaining their current PSAP call disconnect control
   capability, while other jurisdictions would like to regain access to
   those capabilities.

only partly a true representation of the current situation.

The document says:

   When PD-1 is enforced, the call taker must be able to cause
      alerting to the caller which has attempted to prematurely
      disconnect from the emergency call.
     Rationale:  The caller believes they have disconnected.  The
      ability to alert is needed to encourage the caller to reconnect.

Previous parts of the document have described "ringback"
as distinct from call back.  Is this "ringback" in requirements
form?

I understand that the folks working on this feel strongly about
this, but this document is neither complete nor persuasive.  As
it stands, it is missing all discussion of the negotiation phase of
this, which has been pointed out repeatedly as a necessary item.
Without the requirements there describing what the negotiation
of this function must do, the security considerations are paper
thin and the rest of it gives no real sense of the overarching system.

Can a phone say "no" in this negotiation, so that the PSAP is
told it is not being surrendered call control?  Without answers
to questions like this, the document can't be evaluated well.

I also believe that to be truly persuasive the document would
have to cover the UI issues and the multi-line issues which have
been raised repeatedly.  As it is, I read it to describe a system
that could just as easily be handled entirely by UI and client
side mechanisms, with no network requirements at all for
abandonment. 

I do not support this document becoming a working group item
as it currently stands. 
			regards,
				Ted Hardie

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 6 Jan 2009 11:14:07 -0500

Called Party Hold is no longer universally available.

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

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

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

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, January 05, 2009 6:02 PM
To: Brian Rosen; 'ECRIT'
Subject: Re: [Ecrit] FW: I-D
Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt

The document says:

The PSTN has a feature

   Some jurisdictions are

The document says:

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Jan 2009 10:10:02 -0800

>Called Party Hold is no longer universally available.

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

>capability and others wishing to regain it is entirely true.

>  It is the fact
>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,

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.

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

>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

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.

>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

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit