Fix issue where recall would not happen when it should.
authorMark Michelson <mmichelson@digium.com>
Mon, 12 Apr 2010 22:27:07 +0000 (22:27 +0000)
committerMark Michelson <mmichelson@digium.com>
Mon, 12 Apr 2010 22:27:07 +0000 (22:27 +0000)
commit69c252c290747cb18c767249c448112a40b4fe76
tree6b566ce2bd65c76548619e58f7b1809640428c31
parent47d8fdae97ed6f1d9f2e913af6c2f7be8ea83a03
Fix issue where recall would not happen when it should.

Specifically, the situation would happen when multiple
callers would request CC for a single generically-monitored
device. If the monitored device became available but the
caller did not answer the recall, then there was nothing
that would poke the CC core to let it know that it should
attempt to recall someone else instead.

After careful consideration, I came to the conclusion that
the only area of Asterisk that needed to be touched was the
generic CC monitor. All other types of CC would require something
outside of Asterisk to invoke a recall for a separate device.

This was accomplished by changing the generic monitor destructor
to poke other generic monitor instances if the device is currently
available and the specific instance was currently not suspended.

In order to not accidentally trigger recalls at bad times, the
fit_for_recall flag was also added to the generic_monitor_instance_list
struct. This gets set as soon as a monitored device becomes available.
It gets cleared if a CCNR request triggers the creation of a new
generic monitor instance. By doing this, we don't accidentally try
to recall a device when the monitored device was being monitored
for CCNR and never actually became available for recall in the first
place.

This error was discovered by Steve Pitts during in-house testing
at Digium.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
main/ccss.c