[asterisk-bugs] [Asterisk 0017400]: Writeformat Slin instead Alaw after attendend Transfer when using Answer before Dial without Moh

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17400 
====================================================================== 
Reported By:                schmidts
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17400
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.7 
JIRA:                       SWP-1579 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-05-26 04:05 CDT
Last Modified:              2010-06-19 17:01 CDT
====================================================================== 
Summary:                    Writeformat Slin instead Alaw after attendend
Transfer when using Answer before Dial without Moh
Description: 
I´ve found a Problem when an attendend Transfer is done when the call to
the transfered has an answer before the dial. This only happens when no
Musiconhold is used when dialing and the Call is transfered after the
target of the refer answeres the call. We use Alaw on all phones, and
asterisk uses Slin for the Musiconhold also for the ringing signal before
the call gets answered.


If a call comes in to exten 123 and Phone A answers the Call, set the call
to Hold, then dials 456, wait for Phone B to answer the call and then refer
the call to Phone B the Write Format of the Call leg A stays on Slin. While
the Caller waits for the Attendend Transfer to be finished he hears the
default musiconhold in this case the macroform-cold_day.wav file and the
channel write format is slin, but after the transfer the write format
should go back to alaw. 

i can reproduce this on every call with this simple dialplan:

exten => 123,1,Dial(SIP/phoneA,120)

exten => 456,1,Answer
exten => 456,n,Dial(SIP/phoneB,120)


what i see in the debug is that the Call leg A is on write format slin
while hearing the moh and is set to alaw when moh stops, but then the
masquerade puts it in the structure of call leg C and then the write format
is changed to slin again even call leg C had write format alaw before.
====================================================================== 

---------------------------------------------------------------------- 
 (0123633) schmidts (reporter) - 2010-06-19 17:01
 https://issues.asterisk.org/view.php?id=17400#c123633 
---------------------------------------------------------------------- 
i know why this happens.

cause of the Answer application the channel is allready answered and the
ringing could not indicate directly via sip (180 ringing) so the inband
ringbacktone is played. while playing the ringbacktone the channel
indication is set to 3 which is ok so far.

BUT in app_dial.c in the function wait_for_answer and also dial_exec_full
doesnt check if the caller channel is allready answered.
in the funcation wait_for_answer there is a switch for the frame subclass
like AST_CONTROL_ANSWER, AST_CONTROL_RINGING and so on. 
If in wait_for_answer the frame AST_CONTROL_RINGING occurs the variable
sentringing is set to 1 and later in dial_exec_full the channel indication
is reset to 0 cause of this sentringing. 
But the AST_CONTROL_RINGING frame never occurs cause the channel is
allready answered and the ringing is just inband.
The only controll frame i can see is AST_CONTROL_ANSWER when the target of
the Dial answers the phone.

i´ve looked at the trunk version of app_dial.c and see that after the
wait_for_answer function returned the peer, ast_answer is called:

                if (ast_test_flag64(&opts, OPT_CALLER_ANSWER))
                        ast_answer(chan);

The problem is that in 1.6.2.7 OPT_CALLER_ANSWER doesnt exists, so i dont
know how i could check if the caller channel is already answered.
i tried to just do ast_answer(chan); and this solves my problem, but i
dont know what will cause this change on other things. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-06-19 17:01 schmidts       Note Added: 0123633                          
======================================================================