There is potential for a callflow executor leak when sending a default
error response.

In the field, we found inbound calls that were forwarded to a number
which canceled the request almost immediately. When this happens,
callflows gets a message back from stepswitch that the bridge was
unsuccessful, then looks up the children in the callflow to see if any
handle that specific hangup cause.

In this case (and most configurations) there are no special branches
so it performs a default action which is to send back a SIP error
message. However, while that process is happening, FreeSWITCH has
already forwarded the cancel from the B leg back to the A leg and out
to the carrier.

The particular carrier in this incident then immediately retries the
same call in another zone. When that call gets created in the other
zone, the ecallmgr call control usurps any other call control
processes for that call id, terminating the ecallmgr call control in
the first zone. It is only then that the first callflow sends the
command to publish the SIP error, but with no ecallmgr control process
in that zone anymore, nothing is there to process it. Callflows then
waits indefinitely to hear back if the SIP error message was
processed.

As a general avoidance of similar situations the all infinite wait
times in call command have also been reduced to one day by default,
however if the cluster is servicing things like turret phones they can
set it back to infinity.