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

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 10 Nov 2008 23:13:42 +0200

Hi Brian, 

thanks for the draft update. The document is much better than the previous
version. 

I still have a few questions regarding Section 1.2. "Abandoned Call":

The text is written in such a way that one gets the impression that a
regular callback cannot be used for two reasons: 

 A) No callback information is available 
   (most likely only because of uninitialized emergency calls). 

 B) The callback message from the PSAP does not reach the caller (because of
call forwarding, etc.). 

For (A) we are working on solutions that allows the emergency caller to
still have a temporary contact info and, at the same time, we try to get rid
of uninitialized emergency calls.

For (B) we work on solutions to allow calls from the PSAP to the UAC to
specially marked to prevent these things from happening. 

This is good news: In some sense we are working on solutions in this problem
space already. 

Now, the idea of "keeping" information of the abandoned could be OK once the
SIP exchange is complete. This is also how it is defined. Still, in a
real-world environment I still expect problems. For example, I suspect that
some entities along the SIP signalig path will perform some actions when
they see a BYE (sent as part of the call being abandoned). (Is it correct
that the caller "stopped" the call using a BYE?) For example, an SBC might
clean up resources, free allocated NAT bindings, and close opened firewall
pinholes. As such, even if the PSAP suddenly sends packets (based on the
state it kept alive) then these packets will be dropped on the floor.
Additionally, depending on how long it takes the call taker to "contact" the
emergency caller it is possible that NAT bindings / packet filters at
stateful packet filtering firewalls already got removed (since they time out
rather quickly) based on the lack of data packets being continously sent. 

It could be possible that things do not work too well in many real-world
cases. 

Am I on the wrong track here? 

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Nov 2008 17:15:00 -0500

I think the problems of call back are larger than the problems of keeping
the call up, if that's what you mean.  However, the requirement is rapid
reconnect in the face of some congestion.  If you can get that with call
back, then you can meet the requirements.  I highly doubt that its
reasonably possible to do that, but maybe we can.

I think that things like losing the media sessions, and the effect that has
on call establishment is hard to fix.  Consider a 3 second delay: the user
hangs up.  The phone immediately alerts.  The user picks up.  3 second delay
before the call taker can speak.  Bad.  That's why it says around 1 second
("rapid").  It' pretty tough, especially in congestion, to get <1 sec new
call (call back) establishment.  It could be done if priority treatment was
given to the call along the path.  That seams really hard.  It seems easier
to not drop the calls or the media sessions for the tens of seconds it might
take to try to get the original caller back on the line.  The call taker is
going to move on after a while and drop the call.  I really don't understand
the discussion about networks making better use of resources by allowing the
call to drop and then reconnecting it.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Monday, November 10, 2008 4:14 PM
To: ECRIT
Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01.txt

Hi Brian, 

Ciao
Hannes