Merged revisions 297075 via svnmerge from
authorJeff Peeler <jpeeler@digium.com>
Wed, 1 Dec 2010 17:53:54 +0000 (17:53 +0000)
committerJeff Peeler <jpeeler@digium.com>
Wed, 1 Dec 2010 17:53:54 +0000 (17:53 +0000)
commita46bd43ae8080c273af198f8fcea1274c5cc7e00
treebd91f4f4273ca37a3e41f39eac3bd072d16986b0
parent6a5d6cf860a1b2c4bc11433e48e9998f25ba1912
Merged revisions 297075 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r297075 | jpeeler | 2010-12-01 11:53:13 -0600 (Wed, 01 Dec 2010) | 37 lines

  Merged revisions 297073 via svnmerge from
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2

  ................
    r297073 | jpeeler | 2010-12-01 11:52:46 -0600 (Wed, 01 Dec 2010) | 30 lines

    Merged revisions 297072 via svnmerge from
    https://origsvn.digium.com/svn/asterisk/branches/1.4

    ........
      r297072 | jpeeler | 2010-12-01 11:50:09 -0600 (Wed, 01 Dec 2010) | 23 lines

      Fix not stopping MOH when transfered local channel queue member is answered.

      The problem here is only present when local channels are used with the MOH
      passthru option as well as no optimization (/nm). I will describe the slightly
      bizarre scenario that was used to test, where phones B and C are queue members:

      Phone A dials into a queue with two members using local channels and the above
      options. Phone B answers. Phone A blind transfers phone B into the same queue.
      Phone A hangs up. Phone C answers, but phone B didn't stop playing MOH.

      In this scenario, the unhold frame that should have gotten to phone B never
      arrived due to the masquerade from the blind transfer. This is usually fine
      since app_queue manages the starting and stopping of MOH. However, with the
      passthrough option enabled when app_queue attempts to stop MOH it tries to do
      so on the local channel rather than the real channel. The easiest solution
      was to just make sure to send an unhold frame during the transfer since it
      wouldn't make sense to have MOH playing after a transfer anyway. This only
      modifies SIP transfers, but the other transfers did not seem to be a problem.
      If DTMF based transfers were a problem it might be okay to add ast_moh_stop
      to finishup, but I didn't want to have to add that unless required.

      ABE-2624
    ........
  ................
................

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