Subject: [Ecrit] Request for agenda time to discuss emergency call termination

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Jul 2008 14:16:49 -0700

Howdy,
	I re-read the thread that discussed this with our colleagues
at NENA, and I believe that the group would benefit from some in-person
discussion of the issues.  Could we have a 10-15 minute discussion on 
the agenda?   Failing that, can we arrange a bar BoF on this?
		thanks,
				Ted
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jul 2008 23:51:48 -0500

At 04:16 PM 7/14/2008, Ted Hardie wrote:
>the agenda?

I'd like to understand what about the thread you didn't understand , 
or was otherwise unclear, as this topic pertains to the IETF?

Within that context, and because there is no ID as a central point of 
focus, what would be your topic outline?

Most the point raised was about US jurisdictions allowing caller 
termination, and the counter was

         a) everything is always subject to local laws, and
         b) is there a problem with the race condition between a
            caller and a callee hanging up the phone being worth
            chasing (when measured in fractions of a second)?

>Failing that, can we arrange a bar BoF on this?
>                 thanks,
>                                 Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Jul 2008 22:25:12 -0700

>or was otherwise unclear, as this topic pertains to the IETF?

Part of it was simply what the protocol work, if any, there was
in this requirement.  If there is protocol work needed (for example,
to update LoST's schema so that the rules applicable jurisdiction
were sent down along with things like the dial strings for local
emergency numbers), I'd like to understand the scope of that
work and the anticipated timeline.

On a less "IETF" and more personal level, I'd really like to understand
how the behavior being proposed by some could be considered
best practice (it's clearly current only in some jurisdictions for
wireline phones and not current anywhere for wireless phones).  As
it stands, it appears to violate the principle of least surprise pretty
fundamentally.  My three-year old hits 911, and I hang up.  It works
in some parts of call set up and not others and in some jurisdictions
and not others.  This is good?

>focus, what would be your topic outline?

What changes are being proposed to -phonebcp and -framework?
What are the consequences in follow-on protocol work of those
changes (and, indeed of the current text, since that looks less
clear to me now than it once did)?
And, as above, what is the real best practice here?  (that one
would go first, in a rational discussion, but it's also non-terminating,
so having the others go first with a "for choice a, the changes are XXX"
structure is probably better.

>            chasing (when measured in fractions of a second)?

Sorry for not being clear on the need before; thanks for asking
before we got to Dublin.
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 09:15:57 -0400

As I stated, in many jurisdictions, if your three year old hits 9-1-1 and
you hang up, a cop will appear at your door inquiring if everything is all
right.

It's not true in all jurisdictions, but it is in some.  There is always some
period of time that elapses between the start of a call initiation and the
trigger point for when the PSAP would actually get a notification of an
"abandoned call", but it's usually pretty short.  Certainly as soon as there
is ringing in a current system, hanging up would be recorded as an abandoned
call, and trigger a response in jurisdictions that do respond.

The system used to work that way all of the time (that is, called party hold
was implemented in the original 9-1-1 system in the U.S. and Canada).  It
got lost, much to the regret of many PSAP people.  Getting it back would be
a good thing for them.  However, that is not universally agreed, and even
where they want it, they need ways to have automatic termination on hang up.
That was the basis for my suggestion that if hook state was signaled, then
PSAPs could decide, without negotiation or UA implementation complexity,
whether to hold the call or not.

John Hearty is concerned about interim (before PSAPs are IP capable)
systems, like the NENA "i2" systems.  He has a point about gateways that has
to be respected.

I would definitely support an agenda slot, bar bof or any other venue to
discuss the best way forward on this issue.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ted Hardie
> Sent: Tuesday, July 15, 2008 1:25 AM
> To: James M. Polk; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Ecrit] Request for agenda time to discuss emergency call
> termination
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 15 Jul 2008 15:52:40 +0200

We seem to be confusing two problems here.

If all you need is the cop to appear at the door to enquire if
everything is alright merely means that the original call details need
to be recorded and delivered to the PSAP in some way. In fact all the
information you need is likely to be in the INVITE request that has
already been delivered to the PSAP, closely followed by your BYE
request.

If you desire to reestablish communication from the PSAP to the original
calling UE, that may require a different solution. One solution in this
case could just be emergency callback with compulsory
draft-ietf-sip-answermode support on the phone, rather than trying to
preserve the original session and prohibit BYE requests. 

Note that in those countries that allow privacy on emergency calls, I
suspect that they would not need a solution to either problem anyway.

I am concerned that we seem to be back in trying to impose the PSTN
solution on a system where other solutions may be possible.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Tuesday, July 15, 2008 2:16 PM
> To: 'Ted Hardie'; 'James M. Polk'; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Ecrit] Request for agenda time to discuss 
> emergency calltermination
> 
> As I stated, in many jurisdictions, if your three year old 
> hits 9-1-1 and you hang up, a cop will appear at your door 
> inquiring if everything is all right.
> 
> It's not true in all jurisdictions, but it is in some.  There 
> is always some period of time that elapses between the start 
> of a call initiation and the trigger point for when the PSAP 
> would actually get a notification of an "abandoned call", but 
> it's usually pretty short.  Certainly as soon as there is 
> ringing in a current system, hanging up would be recorded as 
> an abandoned call, and trigger a response in jurisdictions 
> that do respond.
> 
> The system used to work that way all of the time (that is, 
> called party hold was implemented in the original 9-1-1 
> system in the U.S. and Canada).  It got lost, much to the 
> regret of many PSAP people.  Getting it back would be a good 
> thing for them.  However, that is not universally agreed, and 
> even where they want it, they need ways to have automatic 
> termination on hang up.
> That was the basis for my suggestion that if hook state was 
> signaled, then PSAPs could decide, without negotiation or UA 
> implementation complexity, whether to hold the call or not.
> 
> John Hearty is concerned about interim (before PSAPs are IP 
> capable) systems, like the NENA "i2" systems.  He has a point 
> about gateways that has to be respected.
> 
> I would definitely support an agenda slot, bar bof or any 
> other venue to discuss the best way forward on this issue.
> 
> Brian
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Ted Hardie
> > >>         I re-read the thread that discussed this with our 
> > >>colleagues at NENA, and I believe that the group would 
> benefit from 
> > >>some in-person discussion of the issues.  Could we have a 10-15 
> > >>minute discussion on the agenda?
> > >
> > Part of it was simply what the protocol work, if any, there was in 
> > this requirement.  If there is protocol work needed (for 
> example, to 
> > update LoST's schema so that the rules applicable jurisdiction were 
> > sent down along with things like the dial strings for local 
> emergency 
> > numbers), I'd like to understand the scope of that work and the 
> > anticipated timeline.
> > 
> > On a less "IETF" and more personal level, I'd really like to 
> > understand how the behavior being proposed by some could be 
> considered 
> > wireline phones and not current anywhere for wireless 
> phones).  As it 
> > stands, it appears to violate the principle of least 
> surprise pretty 
> > What are the consequences in follow-on protocol work of 
> those changes 
> > (and, indeed of the current text, since that looks less clear to me 
> > now than it once did)?
> > And, as above, what is the real best practice here?  (that 
> one would 
> > go first, in a rational discussion, but it's also 
> non-terminating, so 
> > having the others go first with a "for choice a, the 
> changes are XXX"
> > Sorry for not being clear on the need before; thanks for 
> asking before 
> > we got to Dublin.
> > 				Ted
> > 
> > 
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 10:51:33 -0400

No, the goal of CPH on an abandoned call is to AVOID a response.  If you
don't hang up, then the call can be answered, the call taker can determine
that no response is needed.  If a response is needed, the right response can
be dispatched.  Abandoned calls are problematic: is there a problem or not?
What responders are appropriate?

Alternatively, after the call is completed established, CPH can be used to
make sure the call taker gets all the information needed.

You are correct that we jumped to solutions before defining the problem(s).
We should fix that.  I'll work on requirements.

It's certainly possible to use an auto call back in lieu of CPH on an
existing call, the result is roughly the same thing if:
*Contact really does get you back to the same device (which -phonebcp
requires)

* The mechanics of the device work the right way (that is, it behaves just
like the call was never terminated)

Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2008 9:53 AM
> To: Brian Rosen; Ted Hardie; James M. Polk; [email-masked];
> Subject: RE: [Ecrit] Request for agenda time to discuss emergency
> calltermination
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Jul 2008 09:23:50 -0700

>What responders are appropriate?

And one thing that confuses me here is that two different classes of
abandoned calls seemed to be treated differently.  Canceled calls
and calls terminated by BYE seem to be handled differently;
from the user perspective, these are exactly the same ("I pressed
END on the phone").  They are different only to the internal hops
and geeks like us.

>We should fix that.  I'll work on requirements.

Please be very clear in the requirements on what the user behavior
aspects are, as well as the PSAP desires.  Given that the PSAP desires
here evidently vary considerably across jurisdictions, I am personally
inclined to try to make sure we don't violate the principle of least
surprise over-much to accommodate the variation.   And if there
is real protocol work to be done, some scope discussion in
the slot/bar bof/whatever would be really, really nice.

>like the call was never terminated)

This second seems like a really odd requirement.  If I call 911 and
abandon the call, and I get a call back with an actual ring, why is
that not sufficient?  Why would you want the system to treat it as if the call was
not terminated?  As far as I can tell, that means the call taker is there if I do
whatever my equivalent is for "pick up the handset again" but requires some
other mechanism (howler tone?) to signal me to pick it up.  I understand
that it used to do that, but that was an artifact of how circuits work.
It is a method to meet the underlying requirement (PSAP reconnect
to callers who have abandoned calls) rather than a requirements in
and of itself.

			regards,
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 12:40:39 -0400

> END on the phone").  They are different only to the internal hops
Agree that they shouldn't look different to the user.
I think the only difference is "before dialog established vs after dialog
established" to us geeks.

> the slot/bar bof/whatever would be really, really nice.
Agree, recognizing that in reality, there are some conflicts (your example:
you want to hang up, the PSAP wants you not to hang up).
 
> to callers who have abandoned calls) rather than a requirements in
First of all, there is a difference between "on hook" and "handset put down,
still off hook".  Howler tone is used for the latter, and doesn't need any
standardization really.  The call remains in the same state.

There is a great deal of variation on UI for devices that can be used to
call for help.  I'd like the device to require as few steps as possible to
reconnect the caller.  If you have a handset with no base, and "Send" and
"Answer" buttons and nothing else, we have no choice, the phone rings and
you have to press "Answer".  However, if there was a hook switch, then we
want immediate reconnect.  We have to craft language that provides the right
BCP advice.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 15 Jul 2008 19:27:14 +0200

I must admit I am sitting on the same side of the fence as Ted here.

I would add some further considerations into the discussion:

1)	We obviously are not worrying about compatibility with old SIP
implementations here, as I guess pretty much every existing SIP phone
with a clear key will send a BYE as a result of hitting that key.
Therefore asking a phone not to send BYE is something that phones will
need to build in before it exists out there. So any solution to the
requirements, when we have them, can presumably require new
implementation in the phone before it works.

2)	If there are requirements to solve, then presumably they will
have to be implemented on all SIP phones, even if the networks that need
this requirement are in a minority. It is impossible to roll out phones
with the capability only to areas that need the capability. Therefore
introduction of the extra capability in the phone should not have an
adverse impact on networks (access or core) or on PSAPs that do not need
the capability.

3)	I suspect a solution that prevents BYE being sent only wins over
other solutions to reestablish the call if you are able to preserve both
signalling and media resources for the entire path between UA and PSAP
by doing so. As the cost of preserving radio resources is high in
respect of the number of times such a capability might be used, I
suspect this is the reason why mobile networks do not do it. But there
are also emergency call architectures where reserving resources in the
network for such calls also have an adverse effect. In the UK network,
with geographically centralised PSAPs, emergency calls are not routed
until the resources are available to answer the call. If you are
reserving resources on these paths until the PSAP has determined whether
a further action is required on a discontinued call, then that means
that you are potentially not routeing other emergency calls to the PSAPs
that should still be serviced. Does the routeing and allocation of
resources to other potential emergency calls take priority over the
reservation of resources in case the PSAP wishes to return to a
discontinued call? A simple call in the old PSTN with localised PSAPs,
but a much more difficult question in the modern telecommunications
architectures.

4)	Note that the transition from PSTN to ISDN meant that most
networks because 1st party release, rather than last party release or
any other form of release. Essentially, this is also how SIP works in
terms of the media resources. This means that any requirements for
emergency call in this respect to preserve network resources mean that
the network entities also need to identify emergency calls as distinct
from other types of calls, and do this securely, so that the capability
cannot be used fraudulently.

But I do support that we identify the precise requirements, and
understand those first.

Regards

Keith

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, July 15, 2008 5:41 PM
> To: 'Ted Hardie'; DRAGE, Keith (Keith); 'James M. Polk'; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Ecrit] Request for agenda time to discuss 
> > abandoned calls seemed to be treated differently.  Canceled 
> calls and 
> > calls terminated by BYE seem to be handled differently; 
> from the user 
> > perspective, these are exactly the same ("I pressed END on the 
> > phone").  They are different only to the internal hops and 
> geeks like 
> > us.
> I think the only difference is "before dialog established vs 
> after dialog established" to us geeks.
> 
> > is real protocol work to be done, some scope discussion in the 
> > slot/bar bof/whatever would be really, really nice.
> > >* The mechanics of the device work the right way (that is, 
> it behaves
> > just
> > that not sufficient?  Why would you want the system to 
> treat it as if 
> > the call was not terminated?  As far as I can tell, that means the 
> > call taker is there if I do whatever my equivalent is for 
> "pick up the 
> > handset again" but requires some other mechanism (howler tone?) to 
> > signal me to pick it up.  I understand that it used to do that, but 
> > that was an artifact of how circuits work.
> > It is a method to meet the underlying requirement (PSAP 
> reconnect to 
> > callers who have abandoned calls) rather than a 
> requirements in and of 
> > itself.
> First of all, there is a difference between "on hook" and 
> "handset put down, still off hook".  Howler tone is used for 
> the latter, and doesn't need any standardization really.  The 
> call remains in the same state.
> 
> There is a great deal of variation on UI for devices that can 
> be used to call for help.  I'd like the device to require as 
> few steps as possible to reconnect the caller.  If you have a 
> handset with no base, and "Send" and "Answer" buttons and 
> nothing else, we have no choice, the phone rings and you have 
> to press "Answer".  However, if there was a hook switch, then 
> we want immediate reconnect.  We have to craft language that 
> provides the right BCP advice.
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 13:59:33 -0400

> implementation in the phone before it works.
Yes
> adverse impact on networks (access or core) or on PSAPs that do not need
Yes
> suspect this is the reason why mobile networks do not do it. 
Nah, they don't do it because they didn't have to discuss it with the
emergency guys before they designed the networks.

It's less resources in most circumstances to keep a call up than to tear it
down and re-establish it.  The case here is that one end is trying to end
the call and the other end is trying to keep the call up.  The best way to
solve that is leave the call up until they figure it out.

> But there
First of all, the goals of the next gen emergency calling networks is to be
able to answer ALL calls, even in a mass calling event.  I can get into why
and how we do this, but that is the design goal; answer ALL calls.

Secondly, all of the solutions we are discussing have minimal impact on how
many messages are sent.  We're not significantly increasing or decreasing
the number of messages.

A PSAP decides whether it will answer a new call or call back an old caller.
That decision is solely in its purview.  

As with most SIP networks, you congest on media before you congest on
signaling, but there are always circumstances where signaling congestion
occurs.  No magic is expected.  As in nearly every call center with a well
designed network, you nearly always run out of people before you run out of
signaling or media capacity.   Disasters could change that of course.  On
the other hand, call taker resources are the least expensive resource you
have; better for the call taker to determine what the right thing to do is
rather than blindly dispatch.

> cannot be used fraudulently.
This is why "don't send BYE" is a good solution; you aren't releasing media
resources.  Auto call back is problematic for this reason.

There is the orthogonal issue of identifying call backs and treating them
specially.  So far, we haven't done that, but its useful.  None of the
proposed solutions depend on that, and none of them are subject to abuse.

An emergency call should be identified by the UA, and it then knows whether
to suppress BYE.  I suspect if we keep that rule, we probably do need words
in -framework and -phonebcp that deal with the currently allowed
circumstance that a proxy detects the emergency dialstring.  I suspect that
if the UA doesn't detect the dial string, it doesn't suppress BYE.
Otherwise, that creates an attack vector.

> But I do support that we identify the precise requirements, and
Yah.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Jul 2008 11:17:48 -0700

>emergency guys before they designed the networks.

And your evidence for this is what, exactly? That they patterned
the network behavior on the ISDN behavior?  Did the ISDN
folks also not talk to the emergency guys?  Or did the emergency
guys they talked to say something different from what you
think they are saying now?

>solve that is leave the call up until they figure it out.

Again, this presumes that the side wanting to keep the call up
has its preferences followed in all cases; as has already been pointed
out, there are cases like anonymous emergency calls where
this may be neither practical nor desirable.

>Otherwise, that creates an attack vector.

And how do you propose to let the UA know whether suppress BYE is
expected by a particular PSAP?  If it suppresses BYE and the PSAP
doesn't expect/support that behavior, it's a flat waste, isn't it?

>> But I do support that we identify the precise requirements, and

Yep, we have solid agreement on that step at least.

				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 15:36:34 -0400

> think they are saying now?

I will give you a dozen old timers in the PSAP world who will tell you that
they howled and screamed when the telcos took away called party hold.

I will give you many more folks who learned how mobile networks worked when
the call started coming in.  In fact, the first discussions with the mobile
guys and 9-1-1 are eerily familiar (this isn't really a telephony service,
its not replacing wired phones, its not reliable and people won't depend on
it to call 9-1-1).

> this may be neither practical nor desirable.
Anonymity is not linked to called party hold.

It's true that CPH is not used, or required, in some jurisdictions.

I'm looking for a simple solution, and I bias complexity at the PSAP to
complexity at the UA.  Its clear we need to control this feature.  What
won't work, I don't think, is Options negotiation.

> doesn't expect/support that behavior, it's a flat waste, isn't it?
Well, first of all, I've agreed that requirements first, solutions later is
appropriate.

What I proposed was all UAs suppress BYE, and all UAs signal hook state.

The PSAP end can then manually or automatically send BYE upon receipt of on
hook state.

No negotiations.  No optional behavior.  No determining capabilities.

If a jurisdiction does not want to support CPH, they return BYE upon receipt
of on-hook state automatically.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Jul 2008 13:02:52 -0700

>they howled and screamed when the telcos took away called party hold.

You'll give them to me?  Sweet.

In any case, it sounds like this howling and screaming did not result in
either comprehensive regulation to restore this nor did it convince
the wireline telcos to put it back in.  The result is that this is not currently
common practice in all jurisdictions.  Since we are putting together
a general statement of best current practice, that's a pretty important
fact. 

>its not replacing wired phones, its not reliable and people won't depend on

We've crossed a wire here.  I was saying that  you seemed to be assuming
that the mobile network guys didn't understand how emergency calls
worked; you're saying that the emergency calling guys didn't understand
how mobile networks worked.

>Anonymity is not linked to called party hold.

It may be linked to other ways to resolve this same issue.
If the resolution to the requirements involves call-back, rather
than call-party hold, anonymous calls may get different behavior.
The key question is whether that is the desired behavior.  Having
an anonymous caller *be unable to get off the phone without explaining
the call* may not be good; having them get a call back from
911 may also be bad, depending on their reasons for the call
and for the hang-up.

Rolling a cop to those situations may be better or worse, but
it isn't a slam-dunk which is the right thing to do.

>won't work, I don't think, is Options negotiation.

You seem to presume that CPH is "this feature".  Please, let's start
the baseline requirements, not at this level.

>of on-hook state automatically.

As you pointed out, this doesn't work when the UA isn't aware it
is an emergency call.  The "hook state" signalling also strikes me
as something not that easy to model in some of our current devices
and contexts, but we'd need more work on this.

			regards,
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 15 Jul 2008 16:30:14 -0400

> You'll give them to me?  Sweet.
No charge.

> a general statement of best current practice, that's a pretty important
It's a fact, but the removal was undesirable, and in many cases they really
want it back.

However, the request is coming from Canada, who never lost it, and doesn't
want to lose it now.  There are other jurisdictions in the same situation.

> how mobile networks worked.
I'm saying that the wireless guys and the emergency services people have not
had a serious negotiation on the called party hold feature.  Actually, the
wireless folks and the emergency service folks have had a very contentious
and somewhat acrimonious relationship in the U.S., which many on both sides
are trying get away from.  The opportunity for NENA and some of the PSAP
people on the list to participate in the setting of IP based standards
before the calls start coming in is a welcome change, which they sincerely
appreciate.

> 911 may also be bad, depending on their reasons for the call
In nearly all, but not all jurisdictions, there is no such thing as
anonymous emergency calls.  I accept the necessity to support them, because
there are some jurisdictions that require them.  

I'll work on requirements and we'll see where we get to.  So far, as far as
I can see, there are no implications on anonymous emergency calls in the
proposed solutions.

> it isn't a slam-dunk which is the right thing to do.
You, and the IETF, don't get to decide that.  The jurisdictions that roll
cops do.  Even where they do not respond, many jurisdictions really would
like to know why a call was abandoned.

There is decades of experience with called party hold.  The downsides are
pretty small.  I'll still grant that it's a specific solution to a problem,
and we don't need to replicate the solution as long as we solve the problem.

> the baseline requirements, not at this level.
Nah, the "feature" is control of abandoned calls and control of established
calls with pre-mature hang up.  Agree, requirements first.

> and contexts, but we'd need more work on this.
Yeah, agree.  In we're always in danger of implementers cherry picking
features to implement in -phonebcp.  We'll have to be careful in -framework
to explain the rationale, and in the security section of both to deal with
side effects like tricking the UA into thinking it's an emergency call in
order to suppress BYE if that is the solution we arrive at.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 15 Jul 2008 18:23:39 -0400

Brian,

> they howled and screamed when the telcos took away called party hold.

CPH was necessary in the electro-mechanical switch days.  There was no CDR,
no way to post mortem trace a call.  CPH to the PSAPs started to fade as 'E'
9-1-1 was rolled out.  As the PSAPs gained a way to identify the caller, the
need for CPH became less important.  Apparently, some PSAPs have found a use
for CPH in addition to having ANI/ALI.  Of course, they only have this
feature on 35% of the 9-1-1 calls.

Malicious Call Hold used CPH also, but it went by the way of CDRs from
modern digital switches.  Hence, the courts accept switch CDRs as evidence.

I don't believe CPH is supported on SS7, hence this may be the reason
cellular doesn't support it as it's based on a derivative of SS7 (IS41?).

So, my assertion is that CPH is only supported on CAS (channel associated
signaling) trunks.  CCS (common channel signaling) doesn't support such.
SIP is CCS, not CAS.  (I wish it were that easy :^)

Bottom line, CPH is a very antiquated feature.

-Marc-

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 16 Jul 2008 15:05:28 +0200

At least from the 3GPP side, my understanding is that emergency calls
were defined pretty much from day 1. You'll finf the EMERGENCY SETUP
message in very early documents.

My understanding is that for 3GPP networks, there is a tradeoff here,
not a set of absolutes.

The tradeoff is that retaining the emergency call requires retention of
the radio access bearer. It was decided not to retain the radio access
bearer (which on a CS call is kept all the time the call is in
progress). If the radio access bearer is retained for emergency calls,
or worse still for all calls, provision of more radio channels per cell
site, or more cell sites would be required of the operators. The
operators obviously won out against any regulators on this decision,
particular given that the retention is a national capability anyway.

Therefore you cannot assume that just because some PSAPs want it, it
must be provided as a capability. Moreover from the operator side, any
phone requirement that retains the radio access bearer unnecessarily in
a network where this is not required to be supported will not be
accepted. Now obviously the situation gets more complex in IMS over GPRS
circumstances, but I think you will find the same cost tradeoff still
applies.

Regards

Keith

> Sent: Tuesday, July 15, 2008 8:37 PM
> To: 'Ted Hardie'; DRAGE, Keith (Keith); [email-masked]; 
> [email-masked]
> > And your evidence for this is what, exactly? That they 
> patterned the 
> > network behavior on the ISDN behavior?  Did the ISDN folks also not 
> > talk to the emergency guys?  Or did the emergency guys they 
> talked to 
> > say something different from what you think they are saying now?
> 
> I will give you a dozen old timers in the PSAP world who will 
> tell you that they howled and screamed when the telcos took 
> away called party hold.
> 
> I will give you many more folks who learned how mobile 
> networks worked when the call started coming in.  In fact, 
> the first discussions with the mobile guys and 9-1-1 are 
> eerily familiar (this isn't really a telephony service, its 
> not replacing wired phones, its not reliable and people won't 
> depend on it to call 9-1-1).
> 
> 
> > 
> > >It's less resources in most circumstances to keep a call 
> up than to 
> > >tear
> > it
> > >down and re-establish it.  The case here is that one end 
> is trying to 
> > >end the call and the other end is trying to keep the call up.  The 
> > >best way
> > to
> > Again, this presumes that the side wanting to keep the call 
> up has its 
> > preferences followed in all cases; as has already been pointed out, 
> > there are cases like anonymous emergency calls where this may be 
> > neither practical nor desirable.
> I'm looking for a simple solution, and I bias complexity at 
> the PSAP to complexity at the UA.  Its clear we need to 
> control this feature.  What won't work, I don't think, is 
> Options negotiation.
> 
> 
> > 
> > >
> > >to suppress BYE.  I suspect if we keep that rule, we 
> probably do need
> > words
> > >circumstance that a proxy detects the emergency dialstring.  I 
> > >suspect
> > that
> Well, first of all, I've agreed that requirements first, 
> solutions later is appropriate.
> 
> The PSAP end can then manually or automatically send BYE upon 
> receipt of on hook state.
> 
> If a jurisdiction does not want to support CPH, they return 
> BYE upon receipt of on-hook state automatically.
> > 
> > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jul 2008 10:26:36 -0400

Well, I certainly agree that 3GPP mechanisms considered emergency calls from
day 1.  I do think PSAP participation in that effort was minimal, but you
probably can't fault the operators or vendors for that.

I think the notion that CPH on an emergency call is an unnecessary waste of
radio bandwidth which would negatively affect capacity is an argument crying
for statistics.  To be real, the incidence of the problem would have to be
something measured in unit calls per busy hour.  I'd bet the actual
statistic was more like 1/100 of a call per busy hour per MSC.  Many PSAPs
can go a day or more without needing to use CPH, although abandoned
emergency calls in large cities happen pretty frequently.  Lots of things we
do with emergency calls have low incidence, but big impact when you need it.

There also could be some tradeoffs associated with the interaction of CPH
and non-initialized devices.  A really important use for CPH is to help stop
the incidence of inappropriate emergency calls from non-initialized devices.
If you can't hang up such a call, you may not be so willing to place one.
That might help everyone.

Brian

> Sent: Wednesday, July 16, 2008 9:05 AM
> To: Brian Rosen; Ted Hardie; [email-masked]; [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jul 2008 08:28:39 -0700

At 7:26 AM -0700 7/16/08, Brian Rosen wrote:
>for statistics. 

But for those statistics to be useful, you'd need to have a mechanism
to defined.  As Keith's message indicated, a solution that forced
the retention of radio bearers for all calls until the called party
terminated the call or acknowledged termination would have the result
that the radio bearer would be retained on all calls.   That has a very
much larger impact than a solution that clearly identifies which calls need
this behavior, but the lower-impact solution space has a trade-off that you now
have to have two code paths and a way for the terminal and probably the
network to distinguish between them. 

>To be real, the incidence of the problem would have to be

I'd actually been thinking that these calls would make things much worse
from a radio bearer perspective since they would all need CPH.  Since the
caller has only to say "Sorry, mis-dial" or the equivalent, I am not sure
how much of a deterrent CPH  would be.  Actually rolling the police would
be much more, since a lot of these are grey market phones.  The costs
on *that* are, of course, much, much higher.

					Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jul 2008 14:29:18 -0400

In IETF protocols, we know which calls are emergency calls.  In the current
3GPP PS mechanisms, the endpoint, and the network knows which calls are
emergency calls.  Only emergency calls would need CPH.

In current CS, the network knows which calls are emergency calls, although
the endpoints do not.  Only emergency calls would need CPH.

On non initialized phones, the only calls allowed are emergency calls.  They
need CPH.

I don't see the problem.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2008 11:29 AM
> To: Brian Rosen; 'DRAGE, Keith (Keith)'; [email-masked];
> [email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 17 Jul 2008 09:46:04 +0100

Brian Rosen said:
> something measured in unit calls per busy hour.

According to one of my colleagues, the UK telcos handle:

- approximately 15 million genuine 999/112 calls per year, plus
- approximately 15 million silent 999/112 calls from mobiles per year,
  presumed to be from "locked" phones.

I'll let you turn that into bandwidth figures for yourself.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 17 Jul 2008 10:07:43 -0400

How many phones are there?  Most importantly, how many calls to 999/112 in
the busy hour and what is the fraction of those calls to other calls?  You
are making a capacity argument for the RAN.  If the total volume of 999/112
calls vs other calls is a small fraction, you don't have a capacity issue if
you increase the hold time of the 999/112 calls.

UK statistics are a bit off from other countries because of the unfortunate
dial string which is easier to accidentally dial.  U.S. statistics are much
better than that.   There are some PSAPs collecting numbers because the
regulator has opened an inquery into non initialized phones, so we may have
some hard numbers.  Informal numbers I know are less than 10%.

Since the feature only holds the call when the user tries to hang up but the
call taker is not ready to let it hang up, or in the case of a fraudulent or
erroneous 9-1-1 call to determine if it's a genuine call, you have to look
at the incidence of that event and the additional call hold time.  For North
American PSAPs, that's very small, a fraction of a percent of minutes.  

Again, the proposal allows automatic disconnect when handling BYE, if that
is the desired action.

Brian
> From: Clive D.W. Feather [mailto:[email-masked]]
> Sent: Thursday, July 17, 2008 4:46 AM
> To: Brian Rosen
> Cc: 'DRAGE, Keith (Keith)'; 'Ted Hardie'; [email-masked];
> [email-masked]
> Subject: Re: [Ecrit] Request for agenda time to discuss emergency
> calltermination
> 
> Brian Rosen said: