Merged revisions 294125 via svnmerge from
authorRichard Mudgett <rmudgett@digium.com>
Mon, 8 Nov 2010 17:19:04 +0000 (17:19 +0000)
committerRichard Mudgett <rmudgett@digium.com>
Mon, 8 Nov 2010 17:19:04 +0000 (17:19 +0000)
commit18553bb80491592ceadcfc9479e4501837dc3bb6
tree5f0c3493bb642dbe1485ad7ac3618b5e25597caf
parentbbffb7fb0701622786331bd1f7cfdec4a3385e49
Merged revisions 294125 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r294125 | rmudgett | 2010-11-08 11:16:01 -0600 (Mon, 08 Nov 2010) | 33 lines

  valgrind reported references to freed memory during a mISDN hangup collision.

  Bad things have been happening in chan_misdn because the chan_misdn
  channel private struct chan_list is not protected from reentrancy.  Hangup
  collisions have be causing read and write accesses to freed memory.

  Converted chan_misdn struct chan_list to an ao2 object for its reference
  counting feature.

  **********
  Removed an impediment to converting chan_list to an ao2 object.

  The use of the other_ch member in chan_list is shaky at best.  It is set
  if the incoming and outgoing call legs are mISDN.  The use of the other_ch
  member goes against the Asterisk architecture and can even cause problems.

  1) It is used to disable echo cancellation.  This could be bad if the call
  is forked and the winning call leg is not mISDN or the winning call leg is
  not the last mISDN channel called by the fork.  The other_ch would become
  a dangling pointer.

  2) It is used when the far end is alerting to hear the far end's inband
  audio instead of Asterisk's generated ringback tone.  This is bad if the
  call is forked.  You would only hear the last forked mISDN channel and it
  may not be ringing yet.

  The other_ch would become a dangling pointer if the call is later
  transferred.
  **********

  JIRA SWP-2423
  JIRA ABE-2614
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_misdn.c