[Home]

Summary:ASTERISK-02401: Matching on dialstatus in the dialplan as laid out in extensions.conf.sample does not function.
Reporter:twisted (twisted)Labels:
Date Opened:2004-09-14 11:22:00Date Closed:2008-01-15 15:07:26.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:As laid out in the example configuration in the extensions.conf.sample, matching of dialstatus using the '.' match char, fails to match.  Example shown below, and I can recreate this every single time.

I experimented with the '_' pattern match qualifier before the string 's-.' and this created adversely negative effects, as it overrode the static mappings.  We should either fix this problem, which i would have no problem doing except for lack of time and understanding of the matching code, or remove the example from the config.

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

[macro-stdexten]

exten => s,1,Dial(${ARG2},20)
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,VoiceMail(u${ARG1})  ; this works fine
exten => s-NOANSWER,2,Goto(default,s,1)    ; same here
exten => s-BUSY,1,VoiceMail(b${ARG1})      ; and here
exten => s-BUSY,2,Goto(default,s,1)        ; and here
exten => s-.,1,Goto(s-NOANSWER,1)          ; and we break.

Comments:By: Mark Spencer (markster) 2004-09-14 18:34:35

Can you update latest CVS and let me know if that syntax works now?

By: Mark Spencer (markster) 2004-09-15 18:39:47

Hello?  Did you get a chance to see if latest CVS fixed this?

By: robf (robf) 2004-09-15 20:13:00

Mark...  I wasn't the one that reported this problem, and I hadn't experienced it before today, but I'm trying to be helpful...

I set up the following in the dialplan, which I modeled on the problem above.

[test-context]

exten => 1,1,Macro(test-macro)

[macro-test-macro]

exten => s,1,Dial(Zap/18,5)
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-NOTHING,1,VoiceMail(u201)
exten => s-NOTHING,2,Goto(default,s,1)
exten => s-BOGUS,1,VoiceMail(b201)
exten => s-BOGUS,2,Goto(default,s,1)
exten => s-.,1,Playback(auth-thankyou)
exten => s-.,2,Hangup

Picking up Zap/3 (in context test-context), and dialing 1, I did *NOT* hear "thank you".  I don't think I should have.

I hope this was a typo on twisted's part, but the extension in the last line of his dialplan above (and the last two of mine) should start with an underscore, since it's a pattern.

After making that change, I get:

   -- Starting simple switch on 'Zap/3-1'
   -- Executing Macro("Zap/3-1", "test-macro") in new stack
   -- Executing Dial("Zap/3-1", "Zap/18|5") in new stack
   -- Recording last caller '222' for channel 'Zap/18'
   -- Called 18
   -- Zap/18-1 is ringing
   -- Zap/18-1 is ringing
   -- Nobody picked up in 5000 ms
   -- Hungup 'Zap/18-1'
   -- Executing Goto("Zap/3-1", "s-NOANSWER|1") in new stack
   -- Goto (macro-test-macro,s-NOANSWER,1)
   -- Executing Playback("Zap/3-1", "auth-thankyou") in new stack
   -- Playing 'auth-thankyou' (language 'en')
   -- Executing Hangup("Zap/3-1", "") in new stack
 == Spawn extension (macro-test-macro, s-NOANSWER, 2) exited non-zero on 'Zap/3-1' in macro 'test-macro'
 == Spawn extension (test-context, 1, 1) exited non-zero on 'Zap/3-1'
   -- Hungup 'Zap/3-1'

Which is, I believe, what we want to see.

I haven't gone back in CVS to see if I could reproduce twisted's behavior with the pattern properly specified, so I guess this wasn't very scientific of me...

By: robf (robf) 2004-09-15 20:14:25

Oh, uh...

By the way...  The line that says 'recording last caller...' is another patch I'm working on.  You can ignore it for now, but you'll see it again, hopefully in the near future...

By: twisted (twisted) 2004-09-15 22:56:19

sorry, wasn't able to test, but I will tomorrow, assuming we still have power ;)

By: tih (tih) 2004-09-16 00:14:22

The problem was in the ordering of the patterns.  If we do this:

[test]
exten => s,1,goto(s-${FOO})
exten => s-A,1,NoOp(A)
exten => s-B,1,NoOp(B)
exten => s-.,1,NoOp(Other)

(as in the sample config before the latest patches), the "s-." is obviously not going to match anything. Correcting that, by adding a '_' in front of that pattern, what's currently in CVS gives us the following:

*CLI> show dialplan test
[ Context 'test' created by 'pbx_config' ]
 's' =>            1. goto(s-${FOO})                             [pbx_config]
 's-A' =>          1. NoOp(A)                                    [pbx_config]
 's-B' =>          1. NoOp(B)                                    [pbx_config]
 '_s-.' =>         1. NoOp(Other)                                [pbx_config]

This is what we expect.  Only a couple of days ago, though, the '_s-.' would have been at the head of the list, and thus would have matched 's-A' and 's-B' before the specific rules got them.

In other words, it now works right.

On the other hand, I fail to understand why the rules have to be sorted before being applied.  Letting the user specify the order of testing exactly, by the physical ordering in extensions.conf, would seem to me much more in line with the Principle of Least Astonishment.  As it is, I find myself splitting my rules into many contexts, such that ordering is irrelevant within each context, and then I control the ordering by including those contexts into the "real" context in my preferred order.

edited on: 09-16-04 00:26

By: Brian West (bkw918) 2004-09-16 00:37:03

The more proper way is to put the _s-. into its own context then include it...

But that doesn't work on macros I don't think.

bkw

edited on: 09-16-04 08:11

By: Mark Spencer (markster) 2004-09-16 12:14:31

includes do work with macros, it doesn't have to be included by macro though, it's fixed in CVS such that it should put it last.

By: Mark Spencer (markster) 2004-09-16 12:14:39

Fixed in CVS

By: Digium Subversion (svnbot) 2008-01-15 15:07:26.000-0600

Repository: asterisk
Revision: 3777

U   trunk/pbx.c

------------------------------------------------------------------------
r3777 | markster | 2008-01-15 15:07:26 -0600 (Tue, 15 Jan 2008) | 2 lines

Make sure patterns are always last (bug ASTERISK-2401)

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

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