Merged revisions 152535 via svnmerge from
authorSteve Murphy <murf@digium.com>
Wed, 29 Oct 2008 05:01:00 +0000 (05:01 +0000)
committerSteve Murphy <murf@digium.com>
Wed, 29 Oct 2008 05:01:00 +0000 (05:01 +0000)
commit6fad66dfb305fe71140be651a0b4b64fe867a99e
tree5f254ce954a02acbb73b4e76a4f675e21c6eb80e
parentc7367e26be583228e3a0beb5e84cb833de0da552
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines

The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.

If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.

If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.

Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).

All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.

I tested this against the 4 common parking
scenarios:

1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.

2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.

3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.

4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.

No crash.

I also ran the scenarios above against valgrind, and accesses looked good.

........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_dial.c
apps/app_queue.c
include/asterisk/features.h
include/asterisk/pbx.h
main/features.c