<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">
<blockquote style="border: 0px none;"
cite="mid:1392335015.2539.28.camel@triton" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="kharwell@digium.com" photoname="Kevin Harwell"
src="cid:part1.05040206.01000304@digium.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:kharwell@digium.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Kevin Harwell</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Thursday,
February 13, 2014 5:43 PM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div>Greetings,<br><br>There is
a bug currently in Asterisk that essentially boils down to MOH<br>not
being [re]started for an attended transfered call when the<br>transferor
was listening to it.<br><br>For example, here is a specific scenario
(issue ASTERISK-19499): Alice<br>calls Bob, Bob starts a SIP attended
transfer into a confbridge that is<br>set to play music when empty.
Alice hears music since she is now on<br>hold and Bob hears music from
the confbridge. Bob then completes the<br>transfer and then Alice
enters the confbridge, but hears no music.<br><br>This situation occurs
because during the transfer and channel masquerade<br>the application
has no way to know the channel was swapped out. There<br>are a couple
of ways to approach a fix for this:<br><br>1) Use a channel fixup in the
applications that are affected. A small<br>change to the "do
masquerade" function has to be made to get this to<br>work too.<br><br>2)
In the relevant channel drivers when an attended transfer occurs<br>check
to see if MOH is currently playing on the transferor. If so, once<br>the
transfer occurs start MOH on the transferee. This idea was put<br>forth
by Olle Johansson (currently implemented in his<br>rana-moh-queue-transfer-1.8
team branch). Albeit a few changes will<br>have to be made in order to
use it in the main branches, but the idea<br>will essentially remain.<br><br>I
like option 2 as it seems to be a bit less intrusive (no changes to<br>masquerades
and such). Also in 12+ the logic can be put into the bridge<br>transfer
code reducing the changes further.<br><br>Thoughts? Ideas? Something I
have missed or need to be aware of?<br><br>I'll start to move forward
with #2 soon and put it up for review.<br>Comments and feedback always
welcome.<br><br>Thanks!<br><br></div><hr style="border: none 0;
border-top: 1px dotted #B5B5B5; height: 1px;margin:15px 0 0 0"
class="__pbConvHr"> </div>
</blockquote>
I was thinking about this, and one of the things that the masquerade
code currently does is to determine if the original channel in a
masquerade has a "visible indication" on it. A visible indication is
something that is indicated by a control frame and which the user of the
channel can actually tell is being indicated. For instance, if an
AST_CONTROL_RINGING frame is indicated to a channel, the user can hear
ringing. It is a visible indication. If the ringing channel is going to
be part of a masquerade, the masquerade detects that the party has a
visible indication of AST_CONTROL_RINGING on it. After performing all of
the rest of the masquerade operation, any visible indication is then
re-indicated to the masqueraded channel. So in the AST_CONTROL_RINGING
case, the control frame is re-indicated to the channel after the
masquerade so that the channel will still hear ringing.<br>
<br>
Since masquerades already have code in them to attempt to detect
user-perceivable state on the channel, I think you should essentially do
option 2, but do it in the masquerade code instead of in channel
drivers. Here's a summary of my idea for how to do this:<br>
1) Around the same area where the visible indication on the original is
checked, set a variable if AST_FLAG_MOH is set on original.<br>
2) Around the same area where the visible indication is re-indicated on
the original, if the variable you created for AST_FLAG_MOH is set, then
call ast_moh_start() on original to get music playing on the channel
again.<br>
<br>
The advantage to doing it in the masquerade code is that it will work
for situations other than attended transfers (e.g. AMI redirects) and
you won't have to put the same code in multiple places. Since masquerade
code already has a blueprint for how to do this sort of thing, there
shouldn't be much risk in expanding on it.<br>
</body></html>