Summary:	ASTERISK-18083: "r" dial params stop give ringback if M macro used
Reporter:	Alexander Merkulov (arheops)	Labels:
Date Opened:	2011-07-01 13:32:53	Date Closed:	2011-09-12 09:28:34
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:	1.8.4	Frequency of Occurrence	Constant
Related Issues:	is duplicated by ASTERISK-18583 'r' option to Dial() not working as documented
Environment:	linux centos	Attachments:
Description:	if dialplan have following dial command exten => _X.,1,Answer exten => _X.,2,Dial(Local/1234@dialout,,rM(privacy-extended)) when it do ring, it give fake ringback. once called party answer call - it hear prompts from privacy macro, ringing STOP and calling party hear dead sielence. if use m instead of r, all working as usual(play moh upto end of macro) [macro-privacy-extended] exten => s,1,Playback(long-file) when long-file played for called party, calling party hear nothing - just dead sielence. is it clear now p.s sorry, cna't find comment add button.
Comments:	By: Leif Madsen (lmadsen) 2011-07-11 14:28:50.779-0500 Essentially you're saying that in this configuration the two parties can't hear each other after the prompts play? Can you provide the macro that you're using so the issue can be reproduced? By: Kinsey Moore (kmoore) 2011-08-11 14:32:34.274-0500 I am unable to reproduce this on Asterisk 1.8.4 using demo-congrats as the prompt, a SIP channel for inbound, and a DAHDI channel as the outbound on the other side of the local channel.  Could you give some more details about your setup?  Approximately how long is the prompt you are using?  What is the inbound channel type?  What is in extensions.conf in the dialout context? By: Murray Melvin (murraytm) 2011-08-24 15:21:24.095-0500 Maybe I can explain better, as this sounds like a problem I'm having with 1.8.5. Expected functionality: Ringing is played for the calling party all through while the privacy-extended macro is executing. Actual functionality: Ringing is played for the calling party before the macro starts but then goes silent. By: Alexander Merkulov (arheops) 2011-08-24 15:24:11.876-0500 yes, exactly. so caller hear nothing and hangup. By: Alexander Merkulov (arheops) 2011-08-24 15:45:53.265-0500 macro is following: [macro-privacy]; privacy macro. press 1 to connect 2 to congestion exten => s,1,Set(MACRO_RESULT=BUSY) exten => s,n,Noop(features: ${DYNAMIC_FEATURES}) exten => s,n,Read(num,${ARG1},1,3,5) exten => s,n,GotoIf($[ "${num}" == "" ]?99,1); exten => s,n,Noop(PRIVACY  ENTERED ${num}); exten => s,n,Goto(${num},1) exten => 99,1,Noop(PRIVACY NOTHING ENTERED) exten => 99,2,Set(MACRO_RESULT=BUSY) exten => 0,1(hang),Set(MACRO_RESULT=BUSY) exten => 1,1,Set(MACRO_RESULT=) exten => 2,1,Set(MACRO_RESULT=CONGESTION) exten => 3,1,Noop(connect) exten => 3,2,Wait(2) exten => 4,1,Set(MACRO_RESULT=ABORT) exten => i,1,Set(MACRO_RESULT=BUSY) inbound channel is sip. outbound channel is sip too. since extension 3 in this macro called partyu not hear ring anymore. By: Murray Melvin (murraytm) 2011-08-24 15:48:17.346-0500 I have confirmed this still exists in 1.8.6-rc2. The problem doesn't seem to be SIP related because my connections are on a PRI. By: Kinsey Moore (kmoore) 2011-08-25 11:53:26.325-0500 Even given this new macro, I am unable to reproduce the bug.  Could you give me a debug log of the Asterisk console that shows this bug occurring?  Hopefully that will provide additional insight as to the cause of the bug. The behavior I'm seeing given the macro above is that when 3 is pressed, both sides get a busy tone. By: Alexander Merkulov (arheops) 2011-08-25 12:17:14.327-0500 problem is not this macro.. probably  u have not this represented, becuase ur inbound call NOT answered. do answer before. get dialout context like this: [dialout] exten => _X.,1,Wait(10) exten => _X.,2,Answer exten => _X.,3,Wait(100) behavour for caller will be: 10 sec ring, then sielence. must be NO sielence. debug will give u nothing. it not show anything special in debug if compare with musiconhold variant. By: Murray Melvin (murraytm) 2011-08-25 12:27:16.386-0500 I can easily reproduce the problem with this: ** start example dialplan ** [from-pstn] exten => 100,1,Dial(DAHDI/G0/${SOMENUMBER},,rM(demonstrate-bug)) exten => 100,n,Hangup() [macro-demonstrate-bug] exten => s,1,Playback(demo-instruct) ** end example dialplan ** As soon as someone answers SOMENUMBER, the ringing stops for the caller for as long as the macro is executing. By: Kinsey Moore (kmoore) 2011-08-25 16:25:23.308-0500 I'm still unable to reproduce it, but I may now have a clue as to what's going on.  There is an ast_indicate(chan, -1) at the end of do_forward in app_dial.c.  You can avoid that code branch by dialing more than one channel simultaneously (dahdi/1&dahdi/2) or commenting out those 3 lines.  It would be helpful to know for sure if that's the offending indication. By: Murray Melvin (murraytm) 2011-08-26 15:31:34.048-0500 I tried commenting out those lines (app_dial.c: 964-966 in 1.8.6-rc2), recompiling, and reinstalling Asterisk but it didn't help anything. By: Kinsey Moore (kmoore) 2011-08-26 16:55:58.934-0500 I've finally manged to reproduce this.  It seems that the timing of the answer relative to the timing of entry into the macro is relevant to whether the bug manifests.  I'll update once I've got prospective fix. By: Alexander Merkulov (arheops) 2011-08-26 17:36:31.194-0500 if so, maybe u propose temporary fix for this (how to do to NOT reproduce while get expected functional) ? By: Kinsey Moore (kmoore) 2011-08-29 08:06:28.372-0500 The method that was preventing me from reproducing was a very early answer of the remote end (which is not always possible), the other method I've found to work around this is to dial multiple channels using &.  There are different things done in app_dial when only a single channel is dialed vs multiple channels. By: Kinsey Moore (kmoore) 2011-08-29 14:41:40.958-0500 The proper fix is on reviewboard here: https://reviewboard.asterisk.org/r/1398/ By: Murray Melvin (murraytm) 2011-08-31 12:18:50.308-0500 I applied that fix to 1.8.6-rc2 and it solved the problem. By: Kinsey Moore (kmoore) 2011-09-12 09:28:34.039-0500 Fix committed. By: Gareth Blades (gblades_skymarket) 2011-11-21 06:30:12.431-0600 We are experiencing this problem in version 1.8.6.0. I have downloaded version 1.8.7.1 but looking at the source code it doesnt look as if this fix has been incorporated. By: Kinsey Moore (kmoore) 2011-11-21 08:28:51.132-0600 1.8.7.1 was tagged just before this fix made it in and 1.8.8 has been a little delayed, but should be out very soon.  1.8.8 will contain this fix.