Subject: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 06 Oct 2008 18:53:26 +0300

Hi all,

we had a chat with Jon on how to make some progress on the subject of 
"Premature Call Termination" and here is the plan we came up with:

* We delete the sentence that talks about the UAC not generating a BYE 
request in
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt
We progress the document through the IETF process as "planned".

* At the same time we create a design team in ECRIT to work on 
"Premature Call Termination".

Depending on the progress of the design team we are able to incorporate 
the results of it into the document (even at a fairly late stage
of the document process). If the design team does not produce results 
then anything that comes out of it can be seen as an extension to the
Phone BCP document.

We need members for the design team! We have already received the 
commitment of folks from NENA but we also need some guys from the ECRIT 
group. Who is interested in participating?

Ciao
Hannes & Marc

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Oct 2008 11:16:49 -0700

>"Premature Call Termination".

This seems to me to presume a fundamental requirement
and to define the terms in a way that isn't appropriate.
Can we define the deliverables, to clear this up?  For
example, could the design team reasonably determine
that call termination in SIP-based systems was fundamentally
different from the wireline and that wireline models of
what "premature" meant did not apply?  Or does this
presume the Canadian requirements as a new, global
requirement?  Or does this include some negotiation phase
requirement that didn't exist before?

>then anything that comes out of it can be seen as an extension to the

Any design team document that does not go through the full
IETF process can expect an appeal.  This isn't the role of design
teams--they make proposals to a working group, which then has
every opportunity to review them as it would any other input.
The same is true for IETF Last Call review.  Assuming that the
results of this can be incorporated into a document that has
already passed IESG review without updating that document
and going through the process is just not how things work.

>group. Who is interested in participating?

Sorry, maybe I have misunderstood this totally.  How do you have volunteers
from NENA for an IETF document without having announced the need before
today?  Are you planning this as a design team to help NENA define a
requirement in its own documents?  Or is this meant to produce an
IETF document?  If a NENA document, my discussion of design teams
is off-base, and I apologize, but it would be useful to identify the target
here.
			thanks,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Oct 2008 14:27:04 -0400

I agree with Ted's concerns. In particular, "premature call  
termination" has never been defined precisely and many of the fears  
are based on the old single-line physical phone model which just don't  
apply here. Carrying forward notions that apply to black phones with  
rotary dials just seems unhelpful. In particular, the topic is  
strongly connected to call-back and should not be treated in isolation.

Henning

On Oct 6, 2008, at 11:53 AM, Hannes Tschofenig wrote:

> Hi all,
>
> we had a chat with Jon on how to make some progress on the subject  
> of "Premature Call Termination" and here is the plan we came up with:
>
> * We delete the sentence that talks about the UAC not generating a  
> BYE request in
> Depending on the progress of the design team we are able to  
> incorporate the results of it into the document (even at a fairly  
> late stage
> of the document process). If the design team does not produce  
> results then anything that comes out of it can be seen as an  
> extension to the
> Phone BCP document.
>
> commitment of folks from NENA but we also need some guys from the  
> ECRIT group. Who is interested in participating?
>
> Ciao
> Hannes & Marc
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 6 Oct 2008 15:16:51 -0400

It was defined in draft-rosen-ecrit-abpd-reqs-00.  It was:
when on an emergency call, a caller hangs up the call before the call taker
is finished acquiring enough information.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Monday, October 06, 2008 2:27 PM
To: Hannes Tschofenig
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 06 Oct 2008 15:01:20 -0500

This sounds a bit like a subjective thing, verses a quantifiable 
definitive thing.

How exactly does a UAC know when it has achieved this status (i.e., 
provided enough information)?

I assume the goal is to have something in signaling that communicates 
this to the UAC, right?

Or is this merely at the discretion of the called party (i.e., the 
call taker's personal satisfaction)?

Where I'm going with this is that I'm beginning to wonder if, then 
how a signaling protocol document should address this, or should this 
not be dealt with in signaling (which is nearly 100% of what we are 
defining -- only!) IMO...

James

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Oct 2008 13:40:06 -0700

At 12:16 PM -0700 10/6/08, Brian Rosen wrote:
>It was defined in draft-rosen-ecrit-abpd-reqs-00.

The tracker does not find that draft; it does find:

draft-rosen-ecrit-premature-disconnect-rqmts-00.txt

Is that the one you meant?

I do not believe we have WG consensus on that document;
John Hearty had comments on it, as did Keith Drage and James
Polk (at least judging by the thread "Let's make some decisions
regarding draft-rosen-ecrit-premature-disconnect-reqmts", which
is the only one discussing I find in my personal archives).  None
of those seems to have been addressed; nor have the comments
I made on the issue in Dublin.  These were minuted, and Hannes
copied the relevant minutes to the list under the title
"Premature Disconnect (feedback from the meeting)".

Is the design team, then, going to work with Brian to settle
the requirements?  Because if we don't have consensus on
the requirements, the design team seems to have a hard row
to hoe.
			regards,
				Ted

> It was:

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 6 Oct 2008 17:21:20 -0400

No, actually, it's pretty precise.  It's "premature" unless the PSAP says
otherwise (that is, if the caller attempts to disconnect before the PSAP
does, then it's a premature disconnect).

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, October 06, 2008 4:01 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig'
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

James

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 7 Oct 2008 00:45:25 +0200

I believe the previous agreement was that we would get the requirements
drafted, and then decide whether there was consensus to implement those
requirements.

I do not see in Hannes mail any incorporation of this into the process.

Regards

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: Monday, October 06, 2008 7:27 PM
> To: Hannes Tschofenig
> Cc: 'ECRIT'
> termination" has never been defined precisely and many of the 
> fears are based on the old single-line physical phone model 
> which just don't apply here. Carrying forward notions that 
> apply to black phones with rotary dials just seems unhelpful. 
> In particular, the topic is strongly connected to call-back 
> and should not be treated in isolation.
> 
> Henning
> 
> > incorporate the results of it into the document (even at a 
> fairly late 
> > stage of the document process). If the design team does not produce 
> > results then anything that comes out of it can be seen as 
> an extension 
> > to the Phone BCP document.
> >

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 7 Oct 2008 00:45:26 +0200

And during the ecrit meeting I made a request that the draft was updated
to clearly separate the concepts of user, UA and so on, and I believe
that applies here as well.

I am still waiting for that revision.

Regards

Keith 

> On Behalf Of Brian Rosen
> Sent: Monday, October 06, 2008 8:17 PM
> To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
> Cc: 'ECRIT'
> when on an emergency call, a caller hangs up the call before 
> the call taker is finished acquiring enough information.
> 
> Brian
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 06 Oct 2008 19:07:17 -0500

OK, fair, I'm glad we are going in the precise direction.  But I am 
curious about who determines "precise" within the PSAP (per your 
suggestion). Is it the call taker themselves, or is this somehow 
incorporated into a signaling protocol?

It seems like the IETF is concerned with how this can be done in 
signaling somehow.

I'm wonder aloud if this can be done in signaling either 
automatically (as a response or new transaction) to the calling party 
when some automaton determines it has received enough information 
(which is determined by a configurable API to know which fields or 
buckets get filled from the inbound signaling)?

Or if the call taker hits a button - indicating they have enough 
information to allow the caller to terminate the call -- knowing 
there is sufficient location and/or callback information for this call?

To me, these are completely different.  In fact, I could argue that 
the idea that a call taker make a mental decision that they have 
enough information about the caller is something that is a brand new 
type of requirement, and one that inherently doesn't have precedent 
in today's architectures anywhere.  This means we need to look at 
this as a fresh req that may or may not be necessary.

just thinking out loud...

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:34:53 +0300

Hi Ted, 

>This seems to me to presume a fundamental requirement and to 
>define the terms in a way that isn't appropriate.
>example, could the design team reasonably determine that call 
>termination in SIP-based systems was fundamentally different 
>from the wireline and that wireline models of what "premature" 
>meant did not apply?  Or does this presume the Canadian 
>requirements as a new, global requirement?  Or does this 
>include some negotiation phase requirement that didn't exist before?

We obviously have to discuss terminology, if that's your concern. 

>incorporate 
>>the results of it into the document (even at a fairly late 
>stage of the 
>>document process). If the design team does not produce results then 
>>anything that comes out of it can be seen as an extension to 
>the Phone 
>>BCP document.
>
>IETF process can expect an appeal.  This isn't the role of 
>design teams--they make proposals to a working group, which 
>then has every opportunity to review them as it would any other input.
>already passed IESG review without updating that document and 
>going through the process is just not how things work.

I know the process. Don't worry. 

>Sorry, maybe I have misunderstood this totally.  How do you 
>have volunteers from NENA for an IETF document without having 
>announced the need before today?  Are you planning this as a 
>design team to help NENA define a requirement in its own 
>documents?  Or is this meant to produce an IETF document?  If 
>a NENA document, my discussion of design teams is off-base, 
>and I apologize, but it would be useful to identify the target here.
>			thanks,
>				Ted
I thought it would be sensible to involve folks from NENA since the
issue came up there.
I want to make sure that key players from both groups are present. This
is important to make some progress. 

Does my response help? 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:36:00 +0300

I just had to give the topic a name. I selected this one since previous
discussions used this term. 
I am happy to pick a different name for the DT. 

We will obviously go through the terminology first; Brian's doc is the
starting point. 

Ciao
Hannes

>On Behalf Of ext Henning Schulzrinne
>Sent: 06 October, 2008 21:27
>To: Hannes Tschofenig
>Cc: 'ECRIT'
>extension

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:41:25 +0300

Hi Ted, 

>I do not believe we have WG consensus on that document; John 
>Hearty had comments on it, as did Keith Drage and James Polk 
>(at least judging by the thread "Let's make some decisions 
>regarding draft-rosen-ecrit-premature-disconnect-reqmts", 
>which is the only one discussing I find in my personal 
>archives).  None of those seems to have been addressed; nor 
>have the comments I made on the issue in Dublin.  These were 
>minuted, and Hannes copied the relevant minutes to the list 
>under the title "Premature Disconnect (feedback from the meeting)".

We don't have consensus on
draft-rosen-ecrit-premature-disconnect-rqmts-00.txt
We are going to discuss the feedback to that document (during the past
IETF meeting) and also those posted to the list. 

>the requirements?  Because if we don't have consensus on the 
>requirements, the design team seems to have a hard row to hoe.

My plan was to start with the terminology. When we know what we will
look at the requirements. 
After we understood the requirements then we will report back to the
group and figure out what todo next. 
If we come to the conclusion that the requirements are not
accomplishable or that we have all the necessary tools already then we
next steps are easy.

Does this help?

Ciao
Hannes

>			regards,
>				Ted
>
>
>
>> It was:
>>when on an emergency call, a caller hangs up the call before the call 
>>taker is finished acquiring enough information.
>>
>>Brian
>>
>fears are 
>>based on the old single-line physical phone model which just don't 
>>rotary dials just seems unhelpful. In particular, the topic 
>is strongly 
>>connected to call-back and should not be treated in isolation.
>>
>>Henning
>>
>>> late stage of the document process). If the design team does not 
>>> produce results then anything that comes out of it can be 
>seen as an 
>>> extension to the Phone BCP document.
>>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:43:01 +0300

>I believe the previous agreement was that we would get the 
>requirements drafted, and then decide whether there was 
>consensus to implement those requirements.

This is the approach. Sorry that I was imprecise. 

Please note, however, that my mail was mainly intended to find folks
with time and interest to discuss the subject. 
A design team needs folks to get the work started. 

Ciao
Hannes

>> rotary dials just seems unhelpful.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:43:47 +0300

That's a good comment. That's something we should be investigate as
well.  

>On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 07 October, 2008 01:45
>To: Brian Rosen; Henning Schulzrinne; Hannes Tschofenig
>Cc: ECRIT
>And during the ecrit meeting I made a request that the draft 
>was updated to clearly separate the concepts of user, UA and 
>so on, and I believe that applies here as well.
>
>On Behalf 
>> Of Brian Rosen
>the call

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 09:45:01 +0300

Based on this discussion may I put 
* James 
* Ted 
* Henning, and 
* Keith
On the design team? 

Someone else?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 08:47:13 -0400

Uh, me?

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

Sent: Tuesday, October 07, 2008 2:45 AM
To: ext James M. Polk; Brian Rosen; Henning Schulzrinne; Hannes Tschofenig
Cc: ECRIT
Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Someone else?

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Oct 2008 15:48:20 +0300

I counted you in already from the NENA side since you lead the
discussions there. 

>On Behalf Of ext Brian Rosen
>Sent: 07 October, 2008 15:47
>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext James M. Polk'; 
>'Henning Schulzrinne'; 'Hannes Tschofenig'
>Cc: 'ECRIT'

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 10:15:54 -0400

It's manual, not automatic.

When the PSAP call taker decides the call is over, then call termination
occurs.  They release the call (with a button).  In the proposed mechanisms,
the caller cannot terminate until then.

The signaling is how the call taker keeps the call up, how the UA signals
its state (on hook/off hook or its logical equivalent) to the PSAP and how
the PSAP signals various alerts (ringing, howler, etc) to the UA.  The
concern that has to be addressed is making sure that in failure conditions,
we don't "brick" the UA.

Please remember there are two problems:
Premature Disconnect, which is what we are talking about, and "Abandoned
Call", which is where the caller attempts to abandon placing an emergency
call before it is answered by the PSAP.  These really are the same thing,
but the signaling problem is different.  In "Premature Disconnect", the call
completed, the call taker has answered, and conversation started. "Abandoned
Call" is an attempt to take the call down some time between when the
original call was placed and the beginning of that period.

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, October 06, 2008 8:07 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig'
Cc: 'ECRIT'
Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

> >when on an emergency call, a caller hangs up the call before the call
taker

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Oct 2008 10:14:45 -0700

>the caller cannot terminate until then.

Is my memory correct that this mechanism is currently in place
in Canada, desired by some operators in the U.S., but not a universal
practice?  One of my concerns here is that we do not impose this
model onto systems which do not work this way now by encoding
it into the signalling protocols.  If, for example, it is the presumption
of certain types of emergency services (spousal abuse crisis centers,
to take an example), that the caller must always be able to
terminate a call as swiftly and silently as possible, anything that
keeps the call up so that an abusive spouse can hear that a call
is present may be counter-productive.  [This is not meant to reflect
any real-world experience with these centers, as I have none.  This
is simply a way of getting at the idea that the desire to allow
user termination may also occur because of a specific emergency
setting; kidnap and home invasion have been used as examples
in the past.]

>call before it is answered by the PSAP.  These really are the same thing,

I think that is a remarkable presumption.  They may not be the same
thing at all.  In jurisdictions which have multiple response numbers,
for example, an abandoned call might reflect a realization from the
caller that they need to call a different emergency number (I called
the police when the fight started, but before they answered, I realized
we urgently need medical response.  Or, I called for medical help then
saw the bottle that tells me I need a poison-specific response.).

Systems which do not acknowledge that the people making these calls
may have knowledge that causes them to change their response to
an emergency should not be encoded in the signalling in my view.
I am also seriously worried about the interaction of this with the
no-SIM test call problem.  If PSAPs MUST respond to these calls
and handle abandoned calls, abandoned test calls take on an
even more problematic aspect.  At least now, those callers can
hang up when they hear a ring.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 7 Oct 2008 13:48:00 -0400

It is in use in some jurisdictions now.  Canada is an example.  It was
deployed in the U.S., it got lost, and they mostly want it back.  It is not
deployed in some areas.  The requirements state that if it's not needed, it
doesn't stop termination, which implies some feature signaling with the
appropriate defaults.

In jurisdictions that have it deployed, I am not aware of the kind of
problems you were imagining.  The current implementations put the call taker
in charge of signaling alerts.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Oct 2008 14:10:12 -0700

At 10:48 AM -0700 10/7/08, Brian Rosen wrote:
>It is in use in some jurisdictions now.

To clarify, this system works now only with wireline deployments,
not with any cellular technology, right?  What happens in Canada
or other jurisdictions when cell phone callers abandon calls or
disconnect before the call taker would have?

				Ted

> Canada is an example.  It was

---

From: Marc Linsner <[email-masked]>
Date: Tue, 07 Oct 2008 17:28:04 -0400

Brian,

> doesn't stop termination, which implies some feature signaling with the

Remember, in the jurisdictions where this is currently deployed, it works
for only 35% of 9-1-1 calls (as 65% are from cellular).

>> the caller cannot terminate until then.

What document contains the proposed mechanisms?

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 07 Oct 2008 18:42:13 -0500

in-line

>It's manual, not automatic.

I'm wondering if it can/should be automated, that once the receiver 
fills all the fields it needs to fill, the caller can now disconnect 
whenever they wish (because sufficient location has been conveyed, 
and the callback number/URI has been captured - both by the PSAP UAS)....

>occurs.

This means the UAC cannot send a BYE (you can spin it any other way, 
this is the results of what you are looking for)

>  They release the call (with a button).  In the proposed mechanisms,

This seems like the no one can terminate the call until the call 
taker does (which means the caller doesn't have the ability to send a BYE)

>the PSAP signals various alerts (ringing, howler, etc) to the UA.

>The

that would be bad!

>call before it is answered by the PSAP.

The latter of these appears to me to be a prevention of sending a 
CANCEL request, in addition to a BYE... this "feature" is expanding 
(or creeping)

>These really are the same thing,

i.e., sending a CANCEL, regardless of Reason header, is also prevented

I have to think about that one before I agree it's a good idea in all cases.

There's easily one good case for it (robber hangs up the call), one 
annoying case (prank call), and one honest mistaken case (unintended call)

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 08:50:41 -0400

So, what, because wireless carriers refused to implement it, despite
repeated requests to do so, and wireless is now more popular, we should
strike the requirement?

PSAPs I talk to consider this a requirement.  They are VERY unhappy the
carriers do not honor the requirement, in both wireline and wireless, in the
U.S.  Canada is very unhappy about the wireless situation.  Both are adamant
that they have a REQUIREMENT for this capability.

As with any other protocol issue, there are no protocol police.  We can
define the mechanism, but implementation may or may not occur.  The PSAPs
have a requirement.  It comes from experience.  We should honor it I think.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2008 5:28 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Brian,

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Wed, 08 Oct 2008 09:19:07 -0400

Brian,

I have no problem entertaining new requirements.  I simply want the
motivation ("We have to do this because") to be spun correctly.

I also believe this demands a viewpoint from the 'other' party, the PSAP
customer, Joe Citizen.

If in fact a solution can to designed that fulfills the requirement and
protects Joe's desires, I have no problem.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 Oct 2008 10:03:29 -0400

No requirement stands on its own. Particularly in this case, proposed  
solutions have had severe side effects that may well outweigh whatever  
call handling functionality is gained. Thus, we need to look at the  
whole picture, not just one requirement. For example, any such  
mechanism must not brick a caller's phone, must not create the ability  
to eavesdrop on users and must not increase security vulnerabilities.  
It may also help to have a less-mechanism-focused requirement. Since  
the user has placed the receiver on hook (on a traditional phone, at  
least), from a user perspective, this is no different than being  
called back, unless you indeed make the phone non-operable.

In the end, the user also has a right to be left alone. If the caller  
no longer wants to talk to the PSAP, forcing him to do that seems  
inappropriate and may well be against the law (or at least should be,  
in a society that calls itself free). We want to prevent accidental  
disconnects, but the PSAP has no right to take over the user's phone,  
listen to the user's environment without permission or perform other  
intrusive acts. Unfortunately, the current requirement document does  
not reflect any of these concerns.

Henning

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 8 Oct 2008 17:25:13 +0200

So now we seem to be indulging in the discussion of whether we should
honour the requirements.

There are still open issues on the requirements that have been raised.
Until we have got the requirements right, we cannot decide that we
should work on implementing them or not.

Regards

Keith 

> Sent: Wednesday, October 08, 2008 1:51 PM
> To: 'Marc Linsner'
> Cc: 'ECRIT'
> So, what, because wireless carriers refused to implement it, 
> despite repeated requests to do so, and wireless is now more 
> popular, we should strike the requirement?
> 
> PSAPs I talk to consider this a requirement.  They are VERY 
> unhappy the carriers do not honor the requirement, in both 
> wireline and wireless, in the U.S.  Canada is very unhappy 
> about the wireless situation.  Both are adamant that they 
> have a REQUIREMENT for this capability.
> 
> As with any other protocol issue, there are no protocol 
> police.  We can define the mechanism, but implementation may 
> or may not occur.  The PSAPs have a requirement.  It comes 
> from experience.  We should honor it I think.
> 
> Brian
> 
> > deployed in the U.S., it got lost, and they mostly want it 
> back.  It 
> > is
> not
> > deployed in some areas.  The requirements state that if it's not 
> > needed,
> it
> > doesn't stop termination, which implies some feature signaling with 
> > the appropriate defaults.
> 
> Remember, in the jurisdictions where this is currently 
> deployed, it works for only 35% of 9-1-1 calls (as 65% are 
> from cellular).
> 
> > 
> > problems you were imagining.  The current implementations 
> put the call
> taker
> >> When the PSAP call taker decides the call is over, then call 
> >> termination occurs.  They release the call (with a 
> button).  In the 
> >> proposed
> > mechanisms,

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Oct 2008 09:30:12 -0700

At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote:
>whole picture, not just one requirement.

The "whole picture" issue is the key point here, and I agree with
Henning that some of the key issues we need to treat  are
whether the mechanism interferes with the user's use of the phone,
whether it creates security vulnerabilities, and whether it
has privacy implications.  I also worry, personally, that the
introduction of this requirement implies either a new requirement
for a negotiation phase or that other responders take up this
behavior.  Both possibilities introduce fragility into the system
and its deployment.

As an additional point, I really question whether the right place to do this
is in the network protocol.  The majority of this behavior is actually
better achieved in the UI, at least in my opinion.  Having the phone
software disable the terminate button for emergency calls and emit
a warning when it is pressed gets the 80% of the 80/20 with no
protocol behavior at all.  I think you'd have to have some UI
changes anyway, simply because this requirement violates the
principle of least surprise.  If I think pressing the red button ends
a call and it does for every call but calls to 911 in Canada, you're
going to want some additional UI signal to let the user known the
call didn't end. 

Having the PSAPs say "We have a requirement" is a useful part of
the dialog on this, and goodness knows that the IETF is not filled
with the sum total of expertise in this area.  But we may well
have the expertise to say "This belongs in some other part of the
system in a world based on multi-line phones using VoIP; the
circuit switched model for this won't work well here".  In fact,
I think we *have* said that, and we're trying to achieve consensus
while talking past each other.  To quote my favorite flying squirrel:
"That trick never works".

				Ted

>For example, any such

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 13:57:11 -0400

I disagree.

What we have is a bunch of amateurs on how you handle emergency calls trying
to tell the experts that what they want is wrong.

Every one of the kinds of user related issues that have been raised have
occurred enough times that we can listen to the PSAP guys who say "on
balance, its better to have the PSAP control disconnect".  It's not
foolproof, and I agree that we can't brick a phone, and I agree you can
always pull the plug or pull out the battery or whatever.  There are, I
believe, jurisdictions to actively don't want this feature, and others who
insist it is a REQUIREMENT to have the feature.  There a lots who are "it
would be nice".

Sure, UI is important here.  Some text on multiline might be appropriate
that is all about UI and But the IETF problem is the signaling: no one is
arguing that it is sometimes the right thing to let the user disconnect.  So
it's not an absolute, "don't send BYE" or disable the button on the UI.
There is negotiation of the feature.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Hardie
Sent: Wednesday, October 08, 2008 12:30 PM
To: Henning Schulzrinne; Marc Linsner
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

				Ted

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 8 Oct 2008 20:46:12 +0200

Speaking as an amateur who has been working in the telecommunication
industry for 30 years:

There are multiple interests to balance here, and the PSAP provider is
only one of these.

Emergency calls do not override other telecommunication needs, the user
may need to make another call, the telecommunications operator may need
the resources for other purposes, etc. Different regulators specify
different things.

Regards

Keith 

> Sent: Wednesday, October 08, 2008 6:57 PM
> To: 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner'
> Cc: 'ECRIT'
> What we have is a bunch of amateurs on how you handle 
> emergency calls trying to tell the experts that what they 
> want is wrong.
> 
> Every one of the kinds of user related issues that have been 
> raised have occurred enough times that we can listen to the 
> PSAP guys who say "on balance, its better to have the PSAP 
> control disconnect".  It's not foolproof, and I agree that we 
> can't brick a phone, and I agree you can always pull the plug 
> or pull out the battery or whatever.  There are, I believe, 
> jurisdictions to actively don't want this feature, and others 
> who insist it is a REQUIREMENT to have the feature.  There a 
> lots who are "it would be nice".
> 
> Sure, UI is important here.  Some text on multiline might be 
> appropriate that is all about UI and But the IETF problem is 
> the signaling: no one is arguing that it is sometimes the 
> right thing to let the user disconnect.  So it's not an 
> absolute, "don't send BYE" or disable the button on the UI.
> On Behalf Of Ted Hardie
> The "whole picture" issue is the key point here, and I agree 
> with Henning that some of the key issues we need to treat  
> are whether the mechanism interferes with the user's use of 
> the phone, whether it creates security vulnerabilities, and 
> whether it has privacy implications.  I also worry, 
> personally, that the introduction of this requirement implies 
> either a new requirement for a negotiation phase or that 
> other responders take up this behavior.  Both possibilities 
> introduce fragility into the system and its deployment.
> 
> As an additional point, I really question whether the right 
> place to do this is in the network protocol.  The majority of 
> this behavior is actually better achieved in the UI, at least 
> in my opinion.  Having the phone software disable the 
> terminate button for emergency calls and emit a warning when 
> it is pressed gets the 80% of the 80/20 with no protocol 
> behavior at all.  I think you'd have to have some UI changes 
> anyway, simply because this requirement violates the 
> principle of least surprise.  If I think pressing the red 
> button ends a call and it does for every call but calls to 
> 911 in Canada, you're going to want some additional UI signal 
> to let the user known the call didn't end. 
> 
> Having the PSAPs say "We have a requirement" is a useful part 
> of the dialog on this, and goodness knows that the IETF is 
> not filled with the sum total of expertise in this area.  But 
> we may well have the expertise to say "This belongs in some 
> other part of the system in a world based on multi-line 
> phones using VoIP; the circuit switched model for this won't 
> work well here".  In fact, I think we *have* said that, and 
> we're trying to achieve consensus while talking past each 
> other.  To quote my favorite flying squirrel:
> >least), from a user perspective, this is no different than 
> being called 
> >back, unless you indeed make the phone non-operable.
> >
> >> I also believe this demands a viewpoint from the 'other' 
> party, the 
> >> PSAP customer, Joe Citizen.
> >>
> >> If in fact a solution can to designed that fulfills the 
> requirement 
> >> and protects Joe's desires, I have no problem.
> >>
> >> -Marc-
> >>
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 16:42:21 -0400

I do not accept that the telecommunications industry can override a
reasonable requirement like this making an argument that "the operator may
need resources for other purposes".  This is an individual call, and we're
talking about disconnect under control of one of two humans.  There aren't
many 'resources' that are available for 'other purposes'.  PSAPs aren't
dictators, nor do they have veto rights, but this is a pretty reasonable
requirement I believe.  Regulation is an area we have to be cognizant of,
and I do think we will have areas where this gets regulated on or off, but
that just shows that the feature does need to be negotiated.

We have experience here.  Lots of experience.  The experience says that the
value of the feature is much greater than the problems it creates, at least
when implemented the way it is/was implemented.  Different technology brings
different challenges, but the core requirement, and it's value judgment,
doesn't change.  One of the things I have to keep repeating to PSAPs is that
in this change from TDM termination (at the PSAP) to IP termination, lots
and lots of technology is changing.  Nearly every subsystem they now have
will be obsolete. However, the way the call taker handles a call won't
fundamentally change.  They still answer a call the way any call taker in
any call center answers a call, they still "say" the local equivalent of
"9-1-1, what is your emergency?".

The experience answering millions of calls suggests that the caller is
better served when the call taker controls disconnect.  It isn't ALWAYS
true.  It's mostly true.  That's the basis of a good requirement.

Brian
-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2008 2:46 PM
To: Brian Rosen; Ted Hardie; Henning Schulzrinne; Marc Linsner
Cc: ECRIT
Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Regards

Keith

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Oct 2008 14:40:37 -0700

At 1:42 PM -0700 10/8/08, Brian Rosen wrote:
>requirement I believe.

I continue to believe we're talking past each other here, and my experience
has been that folks talking past each other tend to get louder and listen
less.   I'm trying to avoid that by trying to go back to the basics here,
and I hope you'll take that in the spirit meant--trying to avoid this turning
into a situation where anyone stops listening.

 At the base line, I think one of the issues is your use of the term
"requirement".  A group of PSAP operators would like the system
that replaces the current system to have specific characteristics.  One
of the desired characteristics is that only a PSAP call-taker can terminate
a call which has reached the PSAP. 

If Marc is correct, the Canadian jurisdiction PSAPs live without this characteristic
for about two-thirds of their calls.  The system clearly works when this
characteristic is not present.  It may be a very strong desire, but there is
no overall system failure when it is not present.  U.S. PSAPs had this
characteristic and it was dropped, over their objections.  The 911 system
continues to work here, even without this.  Call-backs and other methods
are used instead.   The PSAP operators feel that this is not as good, and they
are the experts on what works for them here; no one is denying this.

But some of us have serious concerns about adding protocol mechanisms
to the ECRIT system to support this characteristic, especially if they necessitate
the introduction of a negotiation phase that is not currently present.  The
risks here are quite real, and they are obvious enough that even amateurs can
see them.  If a negotiation phase adds significant latency, rates of
call abandonment *will* go up.   To take a ridiculous number, if it
takes 20 seconds to do this negotiation, supporting this is out of the
question.  Way too many people will give up completely or be in
seriously worse straits to make that sensible.  That number is clearly
not probable, but it indicates the need to balance.  That same need
for balance is needed in other arenas:  the need to maintain the
privacy of the user may be mandated or desired in some jurisdictions;
the need to maintain the security of the communication channel; the
need for the caller to make other calls; and, yes, the need to free
resources so that *other* callers can make their own calls
(which in disaster situations may also be to emergency services).  

I know I would feel more like I'm being heard if you acknowledged
that there are other needs to balance here, and I hope you hear that
I understand that PSAP operators have experience with this system
that I do not.
			regards,
				Ted Hardie

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 18:13:25 -0400

Ted

Lots of systems get used even when they don't meet the user's requirements.
That's what happened.  I don't mean to imply that the whole thing won't work
without this feature.  On the other hand, as you know, sometimes
implementers ignore requirements for financial or other reasons.  I don't
think that applies here in ecrit, but it may.  I just don't see how you take
a situation where carriers flat out refused to meet the requirement as
justification for not considering the requirement, or negating its
importance.  The 9-1-1 system "worked" without any location.  When wireless
first started, it didn't provide ANY location at all.  Are you suggesting
that the location reporting requirement be dropped because millions of 9-1-1
calls were completed without it?  

Then, I think you drop immediately into mechanism issues.  You, for example,
get worried about some new negotiation phase.  No one has suggested that.
The proposals that are at the front of the table use the existing
Supported/Required option negotiation mechanism.  The UA indicates that it
can support the option in Supported.  The PSAP indicates that it can
implement the option, and desires to employ it on the specific call, by
including it in Required.  If the UA sees it in Required, and it sent it in
Supported, it enables the function.  If it doesn't understand it, or doesn't
see it in Required, it's not enabled.  In some folk's preferred
implementation, you use the existing Hold signaling (SDP sendrecv=inactive)
to indicate "hook state", and rather than sending BYE from the UA.  The PSAP
terminates the call.  The UA can terminate if it doesn't complete the
ReINVITE that signals a hook state change.  I think that avoids the "brick"
problem.  There is NO added latency.  It doesn't use any resources that
weren't already allocated for the call.  You do something similar with
CANCEL.

Brian (who is still listening)

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2008 5:41 PM
To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc
Linsner'
Cc: 'ECRIT'

and I hope you'll take that in the spirit meant--trying to avoid this
turning

If Marc is correct, the Canadian jurisdiction PSAPs live without this
characteristic
for about two-thirds of their calls.  The system clearly works when this
characteristic is not present.  It may be a very strong desire, but there is
no overall system failure when it is not present.  U.S. PSAPs had this
characteristic and it was dropped, over their objections.  The 911 system
continues to work here, even without this.  Call-backs and other methods
are used instead.   The PSAP operators feel that this is not as good, and
they
are the experts on what works for them here; no one is denying this.

to the ECRIT system to support this characteristic, especially if they
necessitate
risks here are quite real, and they are obvious enough that even amateurs
can

---

From: Marc Linsner <[email-masked]>
Date: Wed, 08 Oct 2008 19:09:54 -0400

Brian,

What document contains your proposed mechanisms?

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Oct 2008 19:35:37 -0400

Right now, it's in a NENA doc, because we thought we were supposed to finish
the requirements before starting on the mechanisms.

We'll bring it into ecrit as soon as its needed.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2008 7:10 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

Brian,

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 Oct 2008 19:46:55 -0400

Brian,

as I've tried to explain to you, this mechanism doesn't work and  
redefines existing SIP behavior by using the Require mechanism, which  
is a no-no. It's essentially a kludge. ECRIT shouldn't be redefining  
SIP, but having NENA do it seems even less appropriate. These end-runs  
don't exactly induce confidence. NENA has to trust IETF  
"representatives" to know their SIP stuff, but that relies on those  
representatives not riding off on their own.

I'm sorry, but this smells, badly.

Henning

---

From: Marc Linsner <[email-masked]>
Date: Thu, 09 Oct 2008 08:12:15 -0400

Brian,

What was your comment about amateurs?

:^)

-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 9 Oct 2008 16:13:39 +0300

Folks, we need to get things going. Here is my suggestion:

1) Read through Brian's draft again
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00
.txt
2) Take a look at the previously received comments 
   - during the IETF meeting
   - after the meeting on the list
   Here are some links:  
http://www.ietf.org/mail-archive/web/ecrit/current/msg05450.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg05447.html
3) Determine whether we can agree on some of the requirements. 

Ciao
Hannes

>On Behalf Of ext Marc Linsner
>Sent: 09 October, 2008 15:12
>To: Brian Rosen
>Cc: 'ECRIT'
>> Right now, it's in a NENA doc, because we thought we were 
>supposed to 
>> finish the requirements before starting on the mechanisms.
>> 
>>> That's what happened.  I don't mean to imply that the whole thing 
>>> won't
>> work
>>> implementers ignore requirements for financial or other reasons.  I 
>>> don't think that applies here in ecrit, but it may.  I just 
>don't see 
>>> how you
>> take
>>> a situation where carriers flat out refused to meet the requirement 
>>> as justification for not considering the requirement, or 
>negating its 
>>> first started, it didn't provide ANY location at all.  Are you 
>>> suggesting that the location reporting requirement be 
>dropped because 
>>> millions of
>> 9-1-1
>>> Supported/Required option negotiation mechanism.  The UA indicates 
>>> that it can support the option in Supported.  The PSAP 
>indicates that 
>>> it can implement the option, and desires to employ it on 
>the specific 
>>> call, by including it in Required.  If the UA sees it in Required, 
>>> and it sent it
>> in
>>> to indicate "hook state", and rather than sending BYE from the UA.  
>>> The
>> PSAP
>>> problem.  There is NO added latency.  It doesn't use any resources 
>>> that weren't already allocated for the call.  You do something 
>>> similar with CANCEL.
>>> 
>>>> reasonable requirement like this making an argument that "the 
>>>> operator
>> may
>>>> need resources for other purposes".  This is an individual 
>call, and
>> we're
>>>> many 'resources' that are available for 'other purposes'.  PSAPs 
>>>> aren't dictators, nor do they have veto rights, but this 
>is a pretty 
>>>> reasonable requirement I believe.
>>> 
>>> turning into a situation where anyone stops listening.
>>> 
>>> "requirement".  A group of PSAP operators would like the 
>system that 
>>> replaces the current system to have specific 
>characteristics.  One of 
>>> the desired characteristics is that only a PSAP call-taker can
>> terminate
>>> characteristic for about two-thirds of their calls.  The system 
>>> clearly works when this characteristic is not present.  It may be a 
>>> very strong desire, but there
>> is
>>> no overall system failure when it is not present.  U.S. PSAPs had 
>>> this characteristic and it was dropped, over their objections.  The 
>>> 911 system continues to work here, even without this.  
>Call-backs and other methods
>>> to the ECRIT system to support this characteristic, especially if 
>>> they necessitate the introduction of a negotiation phase 
>that is not 
>>> currently present.
>> The
>>> risks here are quite real, and they are obvious enough that even 
>>> amateurs can see them.  If a negotiation phase adds significant 
>>> latency, rates of
>>> takes 20 seconds to do this negotiation, supporting this is out of 
>>> the question.  Way too many people will give up completely or be in 
>>> seriously worse straits to make that sensible.  That number is 
>>> clearly not probable, but it indicates the need to balance.  That 
>>> same need for balance is needed in other arenas:  the need to 
>>> maintain the privacy of the user may be mandated or desired in some 
>>> jurisdictions; the need to maintain the security of the 
>communication 
>>> channel; the need for the caller to make other calls; and, yes, the 
>>> need to free resources so that *other* callers can make their own 
>>> calls (which in disaster situations may also be to 
>emergency services).
>>>

---

From: Randall Gellens <[email-masked]>
Date: Fri, 17 Oct 2008 16:20:38 -0700

At 4:13 PM +0300 10/9/08, Hannes (NSN - FI/Espoo) Tschofenig
wrote:

Folks, we need to get things going. Here
is my suggestion:

.txt

Here are some links:

3) Determine whether we can agree on some of the
requirements.

Here is one issue:

In
jurisdiction where there is no CPH and PSAP calls back the
originator,

is CPH and call-back perceived different?(Ted)

Yes it's different. Real problem is you can get Voicemail.. Instead
of

the originator.

Originator can also make a call, with CPH, originator can't make
another

call. (Brian)

Currently, cell phones don't implement CPH, but most do implement
a feature that, for some time period following an emergency call, the
phone can't be used to place a new call unless the user hits "end
call" twice.  The intent, as I understand it, is to
"reserve" the phone for PSAP call-back, while allowing the
user to over-ride this reservation.

It seems to me that this suggests several things that are worth
noting: A lot can and will need to be done in the UI; the user needs
to be able to over-ride any restrictions; keeping the call itself up
is not necessarily the optimal solution, especially in cellular
networks.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly-selected tag: ---------------

I never travel without my diary.  One should always have something

sensational to read on the train.

--Oscar Wilde

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 18 Oct 2008 18:02:18 -0400

You can get voicemail from call forwarding, network congestion, etc, in
addition to making a call.  UI can't fix that.  Interestingly, I don't
recall ever reading anywhere else about the feature you described.  I wonder
if in fact it is implemented widely.  

There isn't anything magic about cellular networks AFAIK; what makes you
believe that cellular networks should be treated differently for emergency
calls?

I'd bet that the outcome where CPH is employed is quite a bit higher than
those where the caller can hang up.  People under stress do stupid things
quite often.  Call takers tend to have better judgment on when a call should
be taken down.  YMMV

I agree that the mechanism must fail safe.

Brian

From: Randall Gellens [mailto:[email-masked]] 
Sent: Friday, October 17, 2008 7:21 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); ext Marc Linsner; Brian Rosen
Cc: ECRIT
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

At 4:13 PM +0300 10/9/08, Hannes (NSN - FI/Espoo) Tschofenig wrote:

Here is one issue:

In jurisdiction where there is no CPH and PSAP calls back the originator,
is CPH and call-back perceived different?(Ted)

Yes it's different. Real problem is you can get Voicemail.. Instead of
the originator.
Originator can also make a call, with CPH, originator can't make another
call. (Brian)

Currently, cell phones don't implement CPH, but most do implement a feature
that, for some time period following an emergency call, the phone can't be
used to place a new call unless the user hits "end call" twice.  The intent,
as I understand it, is to "reserve" the phone for PSAP call-back, while
allowing the user to over-ride this reservation. 

It seems to me that this suggests several things that are worth noting: A
lot can and will need to be done in the UI; the user needs to be able to
over-ride any restrictions; keeping the call itself up is not necessarily
the optimal solution, especially in cellular networks.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only