[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-22 08:52 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0094129) davidw (reporter) - 2008-10-22 08:52
 http://bugs.digium.com/view.php?id=13747#c94129 
---------------------------------------------------------------------- 
Meanwhile, here is some dialplan that simulates the AMI and full dialplan,
sufficiently to reproduce the fault:

exten =>
6185,1,Dial(Local/*6185 at default&Local/http://bugs.digium.com/view.php?id=6185@default,,g)


exten =>
*6185,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1)
exten => *6185,n,Dial(SIP/4222,15)

exten => http://bugs.digium.com/view.php?id=6185,1,Wait(3)
exten =>
http://bugs.digium.com/view.php?id=6185,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1)

To use, dial 700 from one phone, then dial 6185 from another phone.  In
the fault condition, the first phone should not give any ringback
indication, but will set up a call if the phone represented here as
SIP/4222 is answered.

This depends on the 4222 phone not trying to send call progress in band
(it didn't work using a Cisco to PSTN line - which I tried because to try
and avoid getting someone else to help run the test).

The phones we actually used, were: Polycom Soundpoint IP 301 dialled 700,
Polycom Soundpoint IP 320 was 4222, and, although I'm assuming it isn't
critical, 3185 was entered using a Cisco phone, via CCM.

Step 6185:1 is changing the ;2 into ;1 in the local channel name.  The ,g
on the Dial was the result of a wrong turning, but should be harmless. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-22 08:52 davidw         Note Added: 0094129                          
======================================================================