|Summary:||ASTERISK-16150: Writeformat Slin instead Alaw after attendend Transfer when using Answer before Dial without Moh|
|Reporter:||Stefan Schmidt (schmidts)||Labels:|
|Date Opened:||2010-05-26 04:05:27||Date Closed:||2010-07-14 10:57:29|
|Environment:||Attachments:||( 0) debuglog.txt|
( 1) debug-lv10.rtf
( 2) sipdebug.rtf
|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.
****** ADDITIONAL INFORMATION ******
exten => 123,1,Dial(SIP/phonea,30)
exten => 123,n,Hangup
exten => 456,1,Answer()
exten => 456,n,Dial(SIP/phoneb,30)
exten => 456,n,Hangup
context=in_world ; Default context for incoming calls
vmexten=voicemail ; dialplan extension to reach mailbox sets the
disallow=all ; First disallow all codecs
dtmfmode = rfc2833
subscribecontext = outcust
notifyringing = yes
notifyhold = yes
limitonpeers = yes
t38pt_udptl = yes
|Comments:||By: Stefan Schmidt (schmidts) 2010-05-26 04:23:05|
in the attached files there is a core debug level 10 and also a sip debug.
SERVER is the server running asterisk 22.214.171.124
INCOMING-SIP-SERVER serves the incoming call
CALLER-A is my cellphone
CALLED-NR is the number i route to this server.
By: Stefan Schmidt (schmidts) 2010-05-26 09:46:06
i´ve tried out trunk revision r265793 and there this problem does not happens.
so maybe this is a bug which is allready solved in trunk.
By: Leif Madsen (lmadsen) 2010-06-03 11:18:29
Can you provide the actual symptom and error that you're experiencing?
Also, can you provide a full debug of the problem occurring? Thanks!
By: Stefan Schmidt (schmidts) 2010-06-03 12:19:56
the symptom is bad sound quality for the caller who get transfered cause the write code of this call leg is slin instead of alaw. The caller hears mostly a ringing sound or even bad inteference of the opponent. The opponent hears the caller without any quality problem.
a full debug (level 10) is allready attached. The problem which is see starts at row 358 of the debug log. There the Moh is stopped and the channel is set to write format alaw. This is the normal behavior i have seen when the target of the attendend transfer has no answer before the dial.
But on Row 375 of the debug log the write format is set to slin again.
By: Paul Belanger (pabelanger) 2010-06-14 09:05:44
Please attach your debug logs as a .txt file, not .rtf.
We require a complete debug log to help triage the issue.
This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:
By: Stefan Schmidt (schmidts) 2010-06-16 06:34:38
debugfile attached collected as the howto says.
sip conf and extension looks little different but basicly the same.
user 100,200,300 with the same parameters as above
extension: 100,200,300 with answer, Dial(SIP/[1,2,3]00,20), hangup
By: Stefan Schmidt (schmidts) 2010-06-19 15:24:55
i´ve done some further investigation and what i can see is that a channel which has an answer before a dial gots stuck on indication 3 (ring) even the channel is allready answered and up.
without the answer before the dial, the indication also is 3 while its ringing, but in ast_raw_answer the channel is answered and the indication is set to 0.
this indication 3 when happens, in my case, while doing a masquerade will be copied to the transfering channel and then after the refer the ring tone generator is launched which cause the slin format what i see.
By: Stefan Schmidt (schmidts) 2010-06-19 17:01:10
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:
1912: const char *number;
1914:+ if (ast_test_flag64(&opts, OPT_CALLER_ANSWER))
1917: strcpy(pa.status, "ANSWER");
The problem is that in 126.96.36.199 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 a ast_answer(chan); and this solves my problem, but i dont know what will cause this change on other things.
By: Stefan Schmidt (schmidts) 2010-06-22 03:01:57
sorry my fault, OPT_CALLER_ANSWER is only for the "a" parameter of Dial.
i´ve tried it again with trunk, and the problem is also there but it sets the write format to alaw after it tries to start the ringtone generator. but the indication of the call is still wrong with 3.
By: Stefan Schmidt (schmidts) 2010-06-28 07:53:52
is the same as issue 16287
By: Leif Madsen (lmadsen) 2010-07-06 10:54:17
Closed as a duplicate.