Re: [asterisk-users] Including doesn't have any effect

[Julian Beach]

Title: Re: [asterisk-users] Including doesn't have any effect


Hello Frank,

Monday, June 6, 2016, 9:46:47 PM, you wrote:

> 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.

Ah, possibly. I only need to block specific incoming numbers.

Julian


-- 
Best regards,
 Julian                            mailto:jb_s...@trink.co.uk


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Frank Vanoni]

On Mon, 2016-06-06 at 08:08 -0700, Steve Edwards wrote:

> 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. 
[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

 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Frank Vanoni]

On Mon, 2016-06-06 at 17:47 +0100, Julian Beach wrote:

> exten => s,n,GotoIf(${DB_EXISTS(blacklist/${CDR(src)})}?block) ; Check
> whether caller blacklisted

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


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] PJSIP subscribe

[Annus Fictus]

Hello,

I'm trying to use presence with PJSIP and  I have a "issue".

I created correctly hint priorities like:

exten => 1000,hint,PJSIP/1000
exten => 1001,hint,PJSIP/1001

Extension 1000 can subscribe extension 1001 y vice-versa. The problem is 
when the extension 1000 make or receive a call. In the softphone where 
the extension is present on buddy list, the extension appear go offline. 
When hang-up the extension return on-line.


On the Asterisk console the command core show hints show the correct 
state for the extension.


On my tests I used XLite, Bria and Jitsi.

Any hint?

Thank you

Regards.



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] pjsip: occasional sip_transactio Unable to register REGISTER transaction (key exists)

[Michael Maier]

On 06/06/2016 at 04:40 PM, Richard Mudgett wrote:
> On Sun, Jun 5, 2016 at 3:48 AM, Michael Maier  wrote:
> 
>> Hello!
>>
>> I occasionally can see warnings like these during *idle* times in
>> asterisk log (asterisk 13.7.2):
>>
>> [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
>> register REGISTER transaction (key xists)
>> [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
>> register REGISTER transaction (key exists)
>>
>> Nothing more. The third REGISTER package works as expected.
>>
>>
>> What's going on:
>> My phone regularly (each 7.5 minutes) sends REGISTER. Sometimes, those
>> REGISTERs are denied like seen above (mostly already the second REGISTER
>> works and no third REGISTER is needed).
>>
>> The reRegistering of the phone normally works like this (as seen in
>> wireshark):
>>
>> -> REGISTER 06:04:19:285
>> <- 401 Unauthorized 06:04:19:287
>> -> REGISTER 06:04:19:316
>> <- 200 OK   06:04:19:376
>>
>>
>> If warnings happen like the one mentioned above, the following can be
>> seen in wireshark:
>>
>> -> REGISTER 06:11:49:359
>> <- 401 Unauthorized 06:11:49:362
>> -> REGISTER 06:11:49:392Unable ...
>> -> REGISTER 06:11:49:876Unable ...
>> -> REGISTER 06:11:50:868
>> <- 200 OK   06:11:51:634
>>
>> The second, third and fourth register package look completely identical
>> to me according wireshark regarding SIP.
>>
>> Notice the big latency between the fourth register and the following 200
>> OK: there are nearly 0.8 seconds in between in the problem case - but
>> normally, there are just 0.06 seconds between REGISTER and 200 OK!
>>
>> What happened during these 0.8 seconds? Asterisk (and the complete
>> machine) has been completely idle at this time - there wasn't any call
>> or anything other to process.
>>
>> I've got the complete wireshark trace of the situation described above.
>>
> 
> Those key exist messages are due to a race condition.  From what I've

It should be impossible - there couldn't be any race condition at this time.

> seen in the code the messages seem to be benign.
> 
> How may endpoints are registering to your Asterisk?

1 device, which registers 2 different numbers *serially*. Asterisk
didn't do any other things at the time those warnings came up. It was
idle. Completely.

> How often?

Each 7.5 minutes.

> Do you use realtime? 

No.


Regards,
Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Julian Beach]

Title: Re: [asterisk-users] Including doesn't have any effect


On Monday, June 6, 2016, 4:55:12 PM, AJS wrote:

> 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!  :)

Indeed, too much for me too...

exten => s,n,GotoIf(${DB_EXISTS(blacklist/${CDR(src)})}?block) ; Check whether caller blacklisted
[snip additional logging]
exten => s,n,Dial(SIP/phones,30)
exten => s,n,Voicemail(x@work,su)
exten => s,n,Hangup()
exten => s,n(block),GoSub(Handler-MarketingCall,s,1) ; deal with blacklisted callers
[snip]

This is linked to couple of simple routines that allow me to add the current (##666) or last caller (*32) to the blacklist or manually input any other number (*30).

-- 
Best regards,
 Julian                            mailto:jb_s...@trink.co.uk


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Carlos Chavez]

On 6/6/16 10:55 AM, A J Stiles wrote:


On Monday 06 Jun 2016, Markus wrote:

Hi AJ,
Am 06.06.2016 um 10:14 schrieb A J Stiles:

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.

.  stuff deleted  .
you're right, it would be the better solution! But I'm simply too lazy
to implement that. :D

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.


--
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)9116-91161


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[A J Stiles]

On Monday 06 Jun 2016, Markus wrote:
> Hi AJ,
> Am 06.06.2016 um 10:14 schrieb A J Stiles:
> > 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.
> .  stuff deleted  .
> you're right, it would be the better solution! But I'm simply too lazy
> to implement that. :D

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!  :)

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Recent UnixODBC Issues

[Joshua Colp]

Happy Monday all,

Since I sent my previous email a lot has been learnt about our UnixODBC 
problem and a path has emerged ensuring both better performance while
making sure people are not required to upgrade their UnixODBC unless 
they want to.


So what's this mean?

As of Asterisk 13.10.0 our own connection pool will be used in the 
res_odbc module. Under testing this has shown to be more performant than 
the UnixODBC implementation and also does not suffer the slowdown 
present in UnixODBC 2.3.3 and above. As well since our own connection 
pool has a fixed size we can restore behavior to that of previous 
versions so those using UnixODBC 2.3.1 will not experience the crashes 
that have been seen.


This is done by having the default be 1 connection, thus disabling 
connection pooling. To turn connection pooling on you will need to 
ensure you are using UnixODBC 2.3.2 or above with latest database 
connectors and configure a maximum limit on concurrent connections in 
res_odbc.conf. To facilitate figuring out the right limit for your 
environment I've made the current count and limit available using the 
"odbc show" CLI command.


This change is up for review[1] and any feedback would be welcome, both 
from code review itself and testing.


Cheers,

[1] https://gerrit.asterisk.org/#/c/2943/

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] pjsip: occasional sip_transactio Unable to register REGISTER transaction (key exists)

[Richard Mudgett]

On Sun, Jun 5, 2016 at 3:48 AM, Michael Maier  wrote:

> Hello!
>
> I occasionally can see warnings like these during *idle* times in
> asterisk log (asterisk 13.7.2):
>
> [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
> register REGISTER transaction (key xists)
> [2016-06-05 06:11:51] WARNING[27817] pjsip: sip_transactio Unable to
> register REGISTER transaction (key exists)
>
> Nothing more. The third REGISTER package works as expected.
>
>
> What's going on:
> My phone regularly (each 7.5 minutes) sends REGISTER. Sometimes, those
> REGISTERs are denied like seen above (mostly already the second REGISTER
> works and no third REGISTER is needed).
>
> The reRegistering of the phone normally works like this (as seen in
> wireshark):
>
> -> REGISTER 06:04:19:285
> <- 401 Unauthorized 06:04:19:287
> -> REGISTER 06:04:19:316
> <- 200 OK   06:04:19:376
>
>
> If warnings happen like the one mentioned above, the following can be
> seen in wireshark:
>
> -> REGISTER 06:11:49:359
> <- 401 Unauthorized 06:11:49:362
> -> REGISTER 06:11:49:392Unable ...
> -> REGISTER 06:11:49:876Unable ...
> -> REGISTER 06:11:50:868
> <- 200 OK   06:11:51:634
>
> The second, third and fourth register package look completely identical
> to me according wireshark regarding SIP.
>
> Notice the big latency between the fourth register and the following 200
> OK: there are nearly 0.8 seconds in between in the problem case - but
> normally, there are just 0.06 seconds between REGISTER and 200 OK!
>
> What happened during these 0.8 seconds? Asterisk (and the complete
> machine) has been completely idle at this time - there wasn't any call
> or anything other to process.
>
> I've got the complete wireshark trace of the situation described above.
>

Those key exist messages are due to a race condition.  From what I've
seen in the code the messages seem to be benign.

How may endpoints are registering to your Asterisk? How often?
Do you use realtime?  Is your realtime database on the same machine?

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Steve Edwards]

On Mon, 6 Jun 2016, Frank Vanoni wrote:


On Sat, 2016-06-04 at 15:19 -0700, Steve Edwards wrote:


Using a 'goto' to exit from a gosub is a bad idea.


Why?


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.


A better idea would be to set a channel variable and check it's value 
after the return, in the calling context.


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.


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.


Well... I'm not an expert and my approach is by "trial and error". It 
works perfectly. :-)


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.


--
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
https://www.linkedin.com/in/steve-edwards-4244281

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Frank Vanoni]

On Sat, 2016-06-04 at 15:19 -0700, Steve Edwards wrote:

> Using a 'goto' to exit from a gosub is a bad idea. 

Why?

> A better idea would be 
> to set a channel variable and check it's value after the return, in the 
> calling context.

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. 


> Also, can a 'goto' in a subroutine reference an extension in the calling 
> context? Seems weird, but 'dialplan' is a weird language :)

Well... I'm not an expert and my approach is by "trial and error". It
works perfectly. :-)



Frank



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[Markus]

Hi AJ,

Am 06.06.2016 um 10:14 schrieb A J Stiles:

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 :)


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


Regards
Markus



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Including doesn't have any effect

[A J Stiles]

On Saturday 04 Jun 2016, Markus wrote:
> Hi list,
> 
> n00b question, but I can't figure it out:
> 
> [callthrough]
> exten => _+X.,1,NoOp(nothing here)
> #include "blockedall.conf"
> exten => _+X.,n(hangup),Hangup
> exten => _+X.,n(nohangup),GotoIf($["${CALLERID(num)}" =
> "anonymous"]?nocli:cli)
> ... more stuff that is handling the call ...
> 
> I'm putting CLIs that I don't want to be able to call my system into
> blockedall.conf:
> 
> exten => _+X.,n,GotoIf($["${CALLERID(num)}" =
> "+493456789"]?hangup:nohangup) exten => _+X.,n,GotoIf($["${CALLERID(num)}"
> = "+492345678"]?hangup:nohangup) exten =>
> _+X.,n,GotoIf($["${CALLERID(num)}" = "+491234567"]?hangup:nohangup)
> 
> But it never moves to "hangup" when I call from any of those CLIs :-(
> 
> BUT, if I include it directly in extensions.conf, it works:
> 
> [callthrough]
> exten => _+X.,1,NoOp(nothing here)
> exten => _+X.,n,GotoIf($["${CALLERID(num)}" =
> "+493456789"]?hangup:nohangup) exten => _+X.,n(hangup),Hangup
> exten => _+X.,n(nohangup),GotoIf($["${CALLERID(num)}" =
> "anonymous"]?nocli:cli)
> ... more stuff that is handling the call ...
> 
> I made sure that "blockedall.conf" actually gets included by executing
> "dialplan show callthrough".
> 
> What am I missing?

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 :)

-- 
AJS

Note:  Originating address only accepts e-mail from list!  If replying off-
list, change address to asterisk1list at earthshod dot co dot uk .

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users