[asterisk-bugs] [Asterisk 0014709]: [patch] chan_local generates MoH instead of just passing HOLD/UNHOLD further

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14709 
====================================================================== 
Reported By:                dimas
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14709
Category:                   Channels/chan_local
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21.2 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-20 06:27 CDT
Last Modified:              2009-05-26 10:04 CDT
====================================================================== 
Summary:                    [patch] chan_local generates MoH instead of just
passing HOLD/UNHOLD further
Description: 
The fix for the issue 7671 made chan_local to start/stop generation of MoH
for HOLD/UNHOLD indications. Previously chan_local used to just pass these
frames further.

As result of the fix, if a SIP user dials into the MeetMe conference not
directly but by the means of Local channel and then puts the call on hold,
all the participants in the conference hear MoH generated by the
chan_local.
====================================================================== 

---------------------------------------------------------------------- 
 (0105423) davidw (reporter) - 2009-05-26 10:04
 https://issues.asterisk.org/view.php?id=14709#c105423 
---------------------------------------------------------------------- 
It is possible to reconfigure the connections to one side of a local
channel.  When you do that, you need tell its new partner which indications
were in progress.  Doing that avoids the need for the local channel to
generate audio corresponding to the indications.  However, it still
requires memory.

However, because this was not working well, we had to change the local
channel so that it actually did source ringback.  (That one may be fixed
now, but we haven't had a chance to reverify.) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-26 10:04 davidw         Note Added: 0105423                          
======================================================================