Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 29 Oct 2008 15:08:58 +0200

A few clarifying comments:

   PD-1  It must be possible to have the PSAP rapidly re-establish
      communications with a caller that attempts to prematurely
      disconnect from the call.
     Rationale:  Time is paramount when handling emergency calls.
      Keeping resources active and available until the call taker
      determines the call can be terminated saves valuable time.

This seems to assume that a regular call-back is insufficient. Are there
some timing requirements? 

  PD-2  It must be possible for the PSAP to know when the user has
      attempted to prematurely disconnect
     Rationale:  Knowledge of the device state (and caller action) gives
      valuable information to the call taker which may influence how the
      call will be managed going forward.

How would this look like in reality? What information is this? Who
provides it? 

   PD-3  Reconnecting the caller must work reasonably reliably under
      congestion conditions.
     Rationale:  PSAPs require robust mechanisms to perform their tasks.

Unless you have end-to-end QoS mechanisms in place this will not work.
Since we don't have them it will not work

   PD-5  When PD-1 is enforced,the caller must not be able to place
      another call until the PSAP allows the call to be released.
     Rationale:  Priority must be given to the PSAP until such time the
      call taker determines the call can be terminated.

Isn't there a chance to leave orphan state around that leaves the end
host unusable? 

   PD-6  All Media and signaling streams flowing between the caller and
      call taker must be maintained to the extent needed for rapid
      reconnection.
     Rationale:  Media and signaling resources must be available as soon
      as the user re-answers.

This essentially means that one should not tear-down the session. Would
dummy media packets flow? 

   AC-1  It must be possible for the PSAP, or the network that serves
      it, to have abandoned calls complete and stay connected.

This does sound complicated or even impossible. 

I guess it is possible on the PSAP operators side to accept the call
even though the call taker has not picked up the call yet. With many
implementations this will obviously create a lot of confusion where the
caller assumes that he can speak already whereas the call taker has not
picked up the phone..

Missing something? 

   AC-2  AC-1 shall be applied at the earliest possible time in the call
      establishment process.

In an IP-based environment, how would this look like? 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Oct 2008 10:21:38 -0400

See inline prefaced by "<br>"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, October 29, 2008 9:09 AM
To: ECRIT
Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt

This seems to assume that a regular call-back is insufficient. Are there
some timing requirements? 
<br> Well, the notion is no noticeable delay from the user's point of view:
he attempts to disconnect, the phone alerts, he picks up the "call" -- the
call taker should be able to immediately speak to him again.  I guess we
could put a time limit on it if you insist.  ?1 second?  

How would this look like in reality? What information is this? Who
provides it? 
<br>Presumably there is signaling that informs the PSAP.  The call taker's
screen displays an indication that the caller attempted to disconnect.
Depending on how the mechanism works, the call taker may have to manually
react to cause alerting on the user's device, or it may be automatic.  When
the call is re-established (whatever that actually means) the call taker
screen indicates the caller is back "on the line".

Of course, another course of action for the call taker is to terminate.

Unless you have end-to-end QoS mechanisms in place this will not work.
Since we don't have them it will not work
<br>This requirement is probably best met by NOT dropping the signaling or
media sessions.  If the mechanism assumes they are dropped, and then an
attempt is made to re-establish, it's unlikely to work in congestion
conditions.  On the other hand, calls that are up tend to stay up in most
network designs.  Of course, without QoS, you can't guarantee it, which is
why "reasonably reliably" is appropriate.

Isn't there a chance to leave orphan state around that leaves the end
host unusable? 
<br>Well, indeed, some proposed mechanisms (such as just not sending BYE)
have the capability to "brick" the phone.  The later proposals don't do
that.

There is the discussion of what to do with a multi-line phone.  It's not
clear what the right thing to do here is.  The kind of normal "flash, start
another call" thing should not be allowed.  If you had a real multibutton,
multiline, with separate identities, etc, maybe that should be allowed
EXCEPT that, generally, we say disable hold, and normally in order to switch
from one line to another you have to terminate or hold.

This essentially means that one should not tear-down the session. Would
dummy media packets flow? 
<br>I suppose that requires some discussion.  Phonebcp says to disable
silence suppression.  I suppose that means packets flow with silence.

I guess it is possible on the PSAP operators side to accept the call
even though the call taker has not picked up the call yet. With many
implementations this will obviously create a lot of confusion where the
caller assumes that he can speak already whereas the call taker has not
picked up the phone..
<br>There clearly is some point at which no reasonable system could force a
call to go through.  We allow (albeit discourage) networks to detect
emergency calls for example, and if the call was abandoned before the
network determined it was an emergency call, then it couldn't force it to
complete.  I think our working definition is that the signaling reaches the
PSAP, and a reply is received by the endpoint.  This allows a normal
negotiation of features.

Although it's conceivable that the call taker could be delayed in
responding, the sequence as seen by the user is that they attempt to
disconnect, but it doesn't work; the call proceeds.  If they "hang up", the
device should alert.  If they pick up the call again, the call is either
answered, with the call taker on the line, or it's still ringing.  Either
works.

In an IP-based environment, how would this look like? 
<br>Since it seems to be a requirement that the capability is enabled (or
not) by the PSAP, the signaling has to reach the PSAP and be responded to.
I think that is the earliest time.  I'd like it to be earlier, but I don't
think it's practical to make it any earlier.  Hopefully, this is all how
many tenths of a second.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Oct 2008 11:11:55 -0400

Brian,

I realize you are pushing a certain solution, so the discussion is  
largely pointless, but let's try. I think it would be much more  
helpful if the requirements draft, given the controversy, were to be  
edited by somebody without a horse in the race.

> could put a time limit on it if you insist.  ?1 second?

Any human reaction is going to take time, even if the alerting is  
instantaneous, particularly since the user will be startled by the  
alerting (they are not expecting a call and won't know how this  
mechanism works). Thus, a few seconds aren't going to make any real  
difference.

> why "reasonably reliably" is appropriate.

I don't know what difference it makes to the delivery probability of  
IP packets whether a call has been up for ten minutes or ten seconds.  
Or are you talking about gateway resources?

> have the capability to "brick" the phone.  The later proposals don't  

We had already discussed and achieved, I thought, rough consensus  
(minus Brian) that this is not an acceptable requirement since it does  
not leave final control with the user. I strongly object to the  
requirement.

> silence suppression.  I suppose that means packets flow with silence.

This is a bogus requirement with no technical rationale, except some  
strange notion of keeping the pipes warm.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Oct 2008 15:05:05 -0400

First of all, I don't object to changing authors on requirements.  I do
think I can faithfully record consensus, but if chairs want someone else,
I'm fine with handing over the xml file.

I believe the "reconnect" is the time from when the user picks back up from
attempting to disconnect, so his reaction time is not counted.  We certainly
could attempt to more carefully define what we are talking about

In most network designs I am aware of, the reaction to call congestion is
admission control.  Calls in progress stay up, new calls are refused.  I
would like this mechanism to not get caught by that.  There are no
guarantees.

While I'm sympathetic to the generalized notion that users retain control,
I'm persuaded by people who actually have experience that it actually works
better to have the PSAP in control.   As we have said before, there is no
way to really hold the call up; you can always rip the wire out of the wall,
pull out the battery, etc.  Whether there should be some form of override,
and what that should be, is certainly something we can discuss further, and
I'm fully prepared to lose that argument.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2008 11:12 AM
To: ECRIT
Cc: Tschofenig, Hannes (NSN - FI/Espoo); Brian Rosen
Subject: Re: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-00.txt

Brian,

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Oct 2008 22:45:06 -0400

> would like this mechanism to not get caught by that.  There are no

I don't understand the admission control bit. Who is doing admission  
control here? I assume you are not talking RSVP here and I'm not aware  
of SIP proxies doing admission control. This just seems to be a way to  
bias the requirements towards a particular solution.

> I'm fully prepared to lose that argument.

I admit that I see this as a non-negotiable position on my part. The  
interests of the caller and the PSAP are not always aligned. In  
reporting an emergency, possibly to help somebody else, I'm not giving  
up my rights to my device or my Internet connection. In a free  
society, citizens have a right to be left alone, even by a well- 
meaning PSAP.

I'd feel much better about the process if we could make some rough- 
consensus calls soon on these fundamental issues soon, so that we can  
avoid cycling back to the same old issues.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Oct 2008 22:50:36 -0400

> I'm fully prepared to lose that argument.

In reporting an emergency, possibly to help somebody else, I'm not  
giving up my rights to my device or my Internet connection. In a free  
society, citizens have a right to be left alone, even by a well- 
meaning PSAP.

I think we'd make more progress if we could make some rough-consensus  
calls soon on these fundamental issues soon, so that we can avoid  
cycling back to the same old issues where we clearly have different  
opinions and make different trade-offs.

Henning