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

["Brian Rosen" <br at brianrosen.net>]

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:hardie at qualcomm.com] 
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
   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

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit