| Summary: | ASTERISK-13294: Dial() option d is not working | ||
| Reporter: | Dennis DeDonatis (dennisd) | Labels: | |
| Date Opened: | 2009-01-02 15:08:06.000-0600 | Date Closed: | 2009-02-11 17:04:11.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_dial |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 14164.patch | |
| Description: | "-- User hit 1 to disconnect call." doesn't show up and nothing happens when using just the option d and pressing 1 when the call is ringing. If I change the options to md, then it works (after a delay). Also, if I use retrydial, after it retries, then it works perfectly. I have tried this with asterisk-1.6.0.3-rc1 and asterisk-1.6.0 from SVN-branch-1.6.0-r167059M and they both do the same thing. ****** STEPS TO REPRODUCE ****** ;Doesn't work: exten => 513,1,dial(sip/2025,5,d) exten => 1,1,answer() exten => 1,n,playback(tt-monkeys) exten => 1,n,hangup() ;Works (there is a delay after pressing 1): exten => 513,1,dial(sip/2025,5,md) ;Works either during the on hold music or after it dials for the 2nd time: exten => 513,1,retrydial(auth-thankyou,5,3,sip/2025,5,d) ****** ADDITIONAL INFORMATION ****** I am using a purely SIP environment. | ||
| Comments: | By: Mark Michelson (mmichelson) 2009-01-05 12:36:43.000-0600 I'm changing the status of this to "confirmed." I have the same issue occurring for me in my test setup too, and I'm thinking that it may have something to do with the fact that it's a SIP setup being used and RFC2833 DTMF is in use. My assumption is that since RTP has not yet been set up for the call, DTMF cannot be intercepted. I'm going to make a small setup using DTMF INFO instead and see if that changes things any. By: Mark Michelson (mmichelson) 2009-01-05 12:43:34.000-0600 Switching to INFO didn't help. The evidence I'm seeing, though, seems to support what I was originally thinking in regards to not having RTP set up yet. If I add a Playback to the dialplan prior to the Dial, then the d option works properly (though with a delay). For the cases where you got it working, there was early media as well (the 'm' option plays music on hold and using RetryDial plays an announcement file between dial attempts). By: Leif Madsen (lmadsen) 2009-01-05 13:04:15.000-0600 Actually this should be 'Acknowledged' as there are no patches attached to this issue. 'Confirmed' is used when there is an initial implementation of a patch to try, or is there to get more debugging information, but before the patch is ready for wider testing (i.e. Ready For Testing). I will be sure to update the bug guidelines sometime this week as I originally had started on it, but now that I'm working on the bug tracker more, I have a better idea as to what statuses we have, and how I'm using them :) By: Mark Michelson (mmichelson) 2009-01-06 11:11:07.000-0600 Ah, sorry about that blitzrage. By: Leif Madsen (lmadsen) 2009-01-20 14:46:28.000-0600 Assigned to putnopvut since he has reproduced the issue, and perhaps he has some thoughts of how to solve it. Sorry! I waited a while before I assigned something new to you... :) By: Mark Michelson (mmichelson) 2009-02-06 11:19:22.000-0600 I'm just updating this bug to say that it's not being ignored. It's a situation where I know why the problem is occurring. It's exactly as I stated in my first note. There's no RTP session set up, so DTMF isn't being sent or received properly. The problem is that I really don't have a good idea of a way to go about solving this. What I'm thinking is that since DTMF is "early media" in this scenario, we need to send a 183 Session Progress with SDP if an incoming SIP call attempts to Dial using the 'd' option (or if any other options allow for pre-bridge DTMF presses). I'm not really sure of all the implications of such an action, though, so I'm hesitant to just blindly add such a concession without exploring its effects and investigating alternatives. By: Mark Michelson (mmichelson) 2009-02-06 11:49:18.000-0600 I tried my idea out of sending a 183 Session Progress message to the phone if it had the 'd' option enabled, but that did not work properly. The phones on my desk would not actually transmit DTMF in that state even though RTP had been set up. Instead, what appears to work is to answer the call at that point so that the phone will actually attempt to send DTMF. I've attached and tested 14164.patch which does this. It works for me in my setup, and I would appreciate feedback to find out if it works for you as well. The one concern I have about this method is the fact that CDR's for incoming calls may have incorrect answer time and disposition fields as a result. It may be worthwhile to create a way to "answer" a call, signaling-wise, but not actually affect the CDR for the call. I think it shouldn't be a difficult thing to do. For now, though, I'm more interested in the correctness of this patch with regards to actually making the 'd' option to Dial work. Thanks for your patience on this one. By: Mark Michelson (mmichelson) 2009-02-06 16:41:09.000-0600 I have opened a review request regarding this issue. The code being reviewed contains this fix, as well as infrastructure to allow a CDR to not be answered if not desired. The review may be found here: http://reviewboard.digium.com/r/145/ By: Digium Subversion (svnbot) 2009-02-11 16:41:31.000-0600 Repository: asterisk Revision: 174945 U trunk/apps/app_dial.c U trunk/apps/app_dictate.c U trunk/apps/app_waitforsilence.c U trunk/include/asterisk/channel.h U trunk/main/channel.c U trunk/main/pbx.c ------------------------------------------------------------------------ r174945 | mmichelson | 2009-02-11 16:41:30 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue ASTERISK-13294) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174945 By: Digium Subversion (svnbot) 2009-02-11 16:48:11.000-0600 Repository: asterisk Revision: 174946 _U branches/1.6.0/ U branches/1.6.0/apps/app_dial.c U branches/1.6.0/apps/app_dictate.c U branches/1.6.0/apps/app_waitforsilence.c U branches/1.6.0/include/asterisk/channel.h U branches/1.6.0/main/channel.c U branches/1.6.0/main/pbx.c ------------------------------------------------------------------------ r174946 | mmichelson | 2009-02-11 16:48:11 -0600 (Wed, 11 Feb 2009) | 35 lines Merged revisions 174945 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue ASTERISK-13294) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174946 By: Digium Subversion (svnbot) 2009-02-11 16:55:17.000-0600 Repository: asterisk Revision: 174947 _U branches/1.6.1/ U branches/1.6.1/apps/app_dial.c U branches/1.6.1/apps/app_dictate.c U branches/1.6.1/apps/app_waitforsilence.c U branches/1.6.1/include/asterisk/channel.h U branches/1.6.1/main/channel.c U branches/1.6.1/main/pbx.c ------------------------------------------------------------------------ r174947 | mmichelson | 2009-02-11 16:55:17 -0600 (Wed, 11 Feb 2009) | 35 lines Merged revisions 174945 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue ASTERISK-13294) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174947 By: Digium Subversion (svnbot) 2009-02-11 17:03:09.000-0600 Repository: asterisk Revision: 174948 U trunk/apps/app_queue.c ------------------------------------------------------------------------ r174948 | mmichelson | 2009-02-11 17:03:08 -0600 (Wed, 11 Feb 2009) | 35 lines Merged revisions 174945 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue ASTERISK-13294) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174948 By: Digium Subversion (svnbot) 2009-02-11 17:04:11.000-0600 Repository: asterisk Revision: 174949 _U branches/1.6.0/ U branches/1.6.0/apps/app_queue.c ------------------------------------------------------------------------ r174949 | mmichelson | 2009-02-11 17:04:10 -0600 (Wed, 11 Feb 2009) | 42 lines Merged revisions 174948 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r174948 | mmichelson | 2009-02-11 17:03:08 -0600 (Wed, 11 Feb 2009) | 35 lines Merged revisions 174945 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue ASTERISK-13294) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=174949 | ||