12 thoughts on - Including Doesn’t Have Any Effect

• 0) You should use ‘verbose()’ instead of ‘noop()’

  1) If the caller ID matches ‘+493456789’ (the first one), you goto the
  ‘hangup’ label. If it does not match, you goto the ‘nohangup’ label

• Am 04.06.2016 um 21:58 schrieb Steve Edwards:

  Doh! Removed :nohangup from every line but the last one and now it works as it should. Thank you! 🙂

• Another possible approach to blacklist two (or more) specific callers
  (098765432 and 012345678 as example)

  In extension.conf

  #include “blaklist.conf”

  exten => _+x.,1,Gosub(blacklist,s,1)
  exten => _+x.,n,….

  exten => black,1,playback(tt-monkeys)

  In blacklist.conf

  exten => s/098765432,1,Goto(black,1)
  exten => s/012345678,1,Goto(black,1)
  exten => s,1,Return()

• Using a ‘goto’ to exit from a gosub is a bad idea. A better idea would be to set a channel variable and check it’s value after the return, in the calling context.

  Also, can a ‘goto’ in a subroutine reference an extension in the calling context? Seems weird, but ‘dialplan’ is a weird language 🙂

• You missed that you were jumping past the second and subsequent tests, if the first one failed. But that’s already been pointed out.

  But why not call an AGI script, have this check the caller ID against a MySQL
  database and return a status — blocked or not — in a variable? Then you can manage individual number blocking in a much cleaner, more extensible fashion.

  Feel free to ignore me if it sounds like I’m suggesting you walk all the way to the tool shed to fetch a chisel, when you know the screwdriver in your drawer is already up to the job 🙂

• Hi AJ,

  Am 06.06.2016 um 10:14 schrieb A J Stiles:

  you’re right, it would be the better solution! But I’m simply too lazy to implement that. 😀

  Regards Markus

• Why?

  The idea is to update the blacklist.conf whenever I want to add or remove a specific number or an entire area code and leave the extensions.conf untouched and to avoid complex regular expressions.

  Well… I’m not an expert and my approach is by “trial and error”. It works perfectly. 🙂

  Frank

• The purpose of a subroutine (code that is entered by a gosub and exited by a return) is to allow the creation of easily reusable code. It ‘packages’
  complex or frequently used code into a nice little black box. You don’t need to know all the details of what happens in the box and you can use this little box throughout your code without having to tell it where to continue when it has finished — it just ‘knows’ by virtue of it’s implementation.

  A ‘gosub’ is implemented (in most languages) by pushing the address of the instruction following the gosub onto the stack. When the return is executed, this address is popped off the stack and loaded into the program counter.

  Using a ‘goto’ to exit from a subroutine does not ‘pop’ off the return address. If this cycle of pushing addresses and not popping off addresses is repeated enough, you may run out of stack space.

  Think how complex and difficult to maintain your dialplan would be if you had to tell each application (dial(), playback(), set(), etc) where to go when it was finished. Even worse, imagine if each application had a fixed
  “I’m finished” address (priority or label).

  Most programmers consider ‘goto’ to be ‘evil’ because it allows
  (encourages?) lazy design leading to difficult to maintain/reuse code.
  (Google ‘why is goto bad’.) Some languages do not even include a ‘goto’ by design to encourage programmers to write better code.

  The idea is fine. The implementation is flawed.

  It should be implemented as a subroutine (or AGI) and return the success or failure as a channel variable. This will result in an ‘easier to comprehend’ and more maintainable dialplan.

  This ‘design pattern’ (a subroutine) would allow you to reuse this same
  ‘black box’ in other parts of your dialplan.

  Think of ‘the next guy’ — which may be you in a couple of months when the
  ‘finer details’ of your implementation fade. If you jump all around your dialplan it gets very hard to comprehend. If you can see that you execute a little black box and then do something based on an intuitively named channel variable the design and intent is obvious.

  A ‘better’ approach is to learn from the mistakes of others.

  I suspect it ‘works perfectly’ until it’s been running long enough to cause difficult to diagnose problems.

• Are you lazy enough to edit a text file and reload your dialplan, *every single time* someone calls you, that you don’t want to have to speak to ever again?

  Not sure about you, but that sounds way too much like hard work for me! 🙂

• And the BLACKLIST function is not a better option for this? So much simpler than an AGI or even including a file in the dialplan. Every time you modify the dialplan you run the risk of a typo that will prevent something from loading.

• As far as I know, Asterisk’s database/blacklist function only supports exact match of caller ID. If you want to block a specific area code or a block of numbers (eg.
  321-654-8XXX) the blacklist function is useless.

  Correct me if I’m wrong.

  Frank

• [snip]

  Steve

  Thank you very, very much for your answer. I really appreciated your interesting and detailed explanation.

  I’ll go over the books again and rewrite the little “black box” taking in consideration your suggestions.

  Thanks again!

  Best regards

  Frank