[Home]

Summary:ASTERISK-10893: Dial option G does not handle labels under some conditions
Reporter:Jon Webster (jon)Labels:
Date Opened:2007-11-26 17:35:59.000-0600Date Closed:2007-12-05 16:53:22.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 11382.patch
( 1) 11382-2.patch
Description:The G option is able to process the priority at G(label) but not G(label)+1. Using G(s^label) seems to work fine so I'm using that as a workaround.

****** ADDITIONAL INFORMATION ******

[dialtest]
exten => s,1,Dial(SIP/jon,,G(pickup))
exten => s,n(pickup),Goto(jump)
exten => s,n,NoOp(Success!)
exten => s,n,Hangup()
exten => s,n(jump),NoOp(Test)


pbx*CLI> dial s@dialtest
   -- Executing [s@dialtest:1] Dial("OSS/dsp", "SIP/jon||G(pickup)") in new stack
   -- Called jon
   -- SIP/jon-084050a0 is ringing
   -- SIP/jon-084050a0 answered OSS/dsp
[Nov 26 18:35:14] NOTICE[10406]: pbx.c:1855 pbx_extension_helper: Cannot find extension '' in context 'local'
[Nov 26 18:35:14] WARNING[10406]: pbx.c:6339 ast_parseable_goto: Priority 'pickup' must be a number > 0, or valid label
   -- Executing [s@dialtest:2] Goto("OSS/dsp", "jump") in new stack
   -- Goto (dialtest,s,5)
   -- Executing [s@dialtest:5] NoOp("OSS/dsp", "Test") in new stack
 == Auto fallthrough, channel 'OSS/dsp' status is 'UNKNOWN'
<< Hangup on console >>
Comments:By: Jon Webster (jon) 2007-11-26 18:02:15.000-0600

Hrm.. this is stranger than I though. I'm not really sure why s^label works as an argument while label doesn't.

G(4) instructs dial to goto 4@dialtest, but the other leg of the call goes to 5@local. I think Dial looks for the label in dials' context in one leg while the other leg is looking for the label in the calling parties context (in consoles case, local).
By: Mark Michelson (mmichelson) 2007-11-27 13:38:45.000-0600

Here's the issue:

If you only specify a priority or a label as the argument for G, the called channel will not have an extension defined and could possibly have the incorrect context defined. The solution appears to be a simple one. I will upload my patch in a minute.
By: Mark Michelson (mmichelson) 2007-11-27 13:42:35.000-0600

The patch I have uploaded makes sense to me.

It seems redundant and wasteful to call ast_parseable_goto on both the chan and peer channels. Call it a single time to figure out where to send chan. Then since peer will always be sent to the same extension and context, but one priority higher, just copy that information from chan to peer and continue. It works for the sample given in the "Additional Information" section, but I want some confirmation that this works as expected before I commit to 1.4
By: Jon Webster (jon) 2007-11-30 18:08:23.000-0600

Close,

The supplied patch caused both the called and calling party to jump to the same priority. Made the following change and created 11382-2.patch. Dial's G option now works as intended on 1.4.13 with a 21 line fudge. I don't think the huge comment is necessary, but it doesn't hurt...

-peer->priority = chan->priority + 1;
+peer->priority = chan->priority + 2;


By: Mark Michelson (mmichelson) 2007-12-05 16:22:10.000-0600

Ah, thanks for catching my mistake. Also, I will be removing the big comment from the code (or at least limiting it) and letting the commit message do the explaining. Thanks for testing and fixing the patch!
By: Digium Subversion (svnbot) 2007-12-05 16:33:47.000-0600

Repository: asterisk
Revision: 91273

U   branches/1.4/apps/app_dial.c
U   branches/1.4/apps/app_voicemail.c

------------------------------------------------------------------------
r91273 | mmichelson | 2007-12-05 16:33:45 -0600 (Wed, 05 Dec 2007) | 11 lines

The 'G' option for Dial() did not properly handle the case where only a label was
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.

(closes issue ASTERISK-10893, reported by jon, patch by me with correction by jon)


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=91273
By: Digium Subversion (svnbot) 2007-12-05 16:53:22.000-0600

Repository: asterisk
Revision: 91291

_U  trunk/
U   trunk/apps/app_dial.c
U   trunk/apps/app_voicemail.c

------------------------------------------------------------------------
r91291 | mmichelson | 2007-12-05 16:53:21 -0600 (Wed, 05 Dec 2007) | 19 lines

Merged revisions 91273 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r91273 | mmichelson | 2007-12-05 16:35:52 -0600 (Wed, 05 Dec 2007) | 11 lines

The 'G' option for Dial() did not properly handle the case where only a label was
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.

(closes issue ASTERISK-10893, reported by jon, patch by me with correction by jon)


........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=91291