diff options
| author | Jeff Peeler <jpeeler@digium.com> | 2010-12-01 17:53:54 +0000 |
|---|---|---|
| committer | Jeff Peeler <jpeeler@digium.com> | 2010-12-01 17:53:54 +0000 |
| commit | a46bd43ae8080c273af198f8fcea1274c5cc7e00 (patch) | |
| tree | bd91f4f4273ca37a3e41f39eac3bd072d16986b0 /channels | |
| parent | 6a5d6cf860a1b2c4bc11433e48e9998f25ba1912 (diff) | |
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
Diffstat (limited to 'channels')
| -rw-r--r-- | channels/chan_sip.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/channels/chan_sip.c b/channels/chan_sip.c index 128fbd151..da1c2018b 100644 --- a/channels/chan_sip.c +++ b/channels/chan_sip.c @@ -22424,6 +22424,9 @@ static int handle_request_refer(struct sip_pvt *p, struct sip_request *req, int /* For blind transfers, move the call to the new extensions. For attended transfers on multiple servers - generate an INVITE with Replaces. Either way, let the dial plan decided */ + /* indicate before masquerade so the indication actually makes it to the real channel + when using local channels with MOH passthru */ + ast_indicate(current.chan2, AST_CONTROL_UNHOLD); res = ast_async_goto(current.chan2, p->refer->refer_to_context, p->refer->refer_to, 1); if (!res) { |