[asterisk-dev] Attended transfers and MOH

[Olle E. Johansson]

On 14 Feb 2014, at 00:43, Kevin Harwell <kharwell at digium.com> wrote:

> Greetings,
> 
> There is a bug currently in Asterisk that essentially boils down to MOH
> not being [re]started for an attended transfered call when the
> transferor was listening to it.
> 
> For example, here is a specific scenario (issue ASTERISK-19499): Alice
> calls Bob, Bob starts a SIP attended transfer into a confbridge that is
> set to play music when empty.  Alice hears music since she is now on
> hold and Bob hears music from the confbridge.  Bob then completes the
> transfer and then Alice enters the confbridge, but hears no music.
> 
> This situation occurs because during the transfer and channel masquerade
> the application has no way to know the channel was swapped out.  There
> are a couple of ways to approach a fix for this:
> 
> 1) Use a channel fixup in the applications that are affected.  A small
> change to the "do masquerade" function has to be made to get this to
> work too.
> 
> 2) In the relevant channel drivers when an attended transfer occurs
> check to see if MOH is currently playing on the transferor.  If so, once
> the transfer occurs start MOH on the transferee.  This idea was put
> forth by Olle Johansson (currently implemented in his
> rana-moh-queue-transfer-1.8 team branch).  Albeit a few changes will
> have to be made in order to use it in the main branches, but the idea
> will essentially remain.
> 
> I like option 2 as it seems to be a bit less intrusive (no changes to
> masquerades and such).  Also in 12+ the logic can be put into the bridge
> transfer code reducing the changes further.
> 
> Thoughts? Ideas? Something I have missed or need to be aware of?
> 
> I'll start to move forward with #2 soon and put it up for review.
> Comments and feedback always welcome.

CHeck this branch:
http://svnview.digium.com/svn/asterisk/team/oej/rana-moh-queue-transfer-1.8/README.rana-moh-queue-transfer.txt?revision=393703

/O