[asterisk-bugs] [Asterisk 0013747]: Indications are not passed from old peer to new peer during masquerade

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13747 
====================================================================== 
Reported By:                davidw
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   13747
Category:                   Core/Channels
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-20 13:04 CDT
Last Modified:              2008-10-23 12:00 CDT
====================================================================== 
Summary:                    Indications are not passed from old peer to new peer
during masquerade
Description: 
We want to transfer a channel that is already indicating (typically
ringing) to a parked channel, which we do with AMI Originate.  When we do
this, the person on the parked channel has MOH changed to silence until the
ringing channel answers, or otherwise changes indication.

It looks to me as though there may have been some attempt to support this,
but it looks like it copies the indications at the wrong end of the
masquerade.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012548 SIP channel protocol illegally reverses...
====================================================================== 

---------------------------------------------------------------------- 
 (0094207) davidw (reporter) - 2008-10-23 12:00
 http://bugs.digium.com/view.php?id=13747#c94207 
---------------------------------------------------------------------- 
My thought for the day was that one might indicate any indication required,
just after this code in ast_channel_bridge.

   4435         ast_indicate(c0, AST_CONTROL_SRCUPDATE);
   4436         ast_indicate(c1, AST_CONTROL_SRCUPDATE);

However:

1) AST_CONTROL_RINGING seems to cause the bridge to drop out, so one would
need to queue it, or short cut to an exit.

2) I'm not sure if that would result in an unwanted hangup or dialplan
continuation (I think I'm safe from the latter in the case I'm interested
in).  More code reading needed.

3) We seem to have the choice of using the channel state, or a, new,
analogue of visible_indication, in the reverse direction, to choose what to
send.  State doesn't seem to directly correlate with indication, and, in
particular, looks to be controlled by technology drivers, rather than the
core.  An analogue of visible_indication suffers from the problem in the
previous comment, namely that there seem to be pure events as well as state
change indications. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-23 12:00 davidw         Note Added: 0094207                          
======================================================================