Re: [asterisk-dev] ODBC improvements: Community opinions requested

[Brad Watkins]

My preference, certainly, would be the removal of code and allowing
unixODBC to "do its job".  But I also can't speak with any authority about
its fitness for purpose.  I've used unixODBC connection pooling and never
had any issues, but that's merely anecdotal.  I'd definitely like to hear
from other folks about their experiences before saying it's the right way
forward.

Assuming there are no major blockers with using unixODBC's connection
pooling, there is still the issue of end user training.  But given the
potentially positive impact such a change would have, I think it's worth
it.  We'd want to ensure that CHANGES and other documentation was updated
to reflect the change, obviously.

Regards,
- Brad

On Mon, Nov 30, 2015 at 6:14 PM, Mark Michelson 
wrote:

> Hi folks,
>
> I apologize if this ends up being a wall of text
>
> In Asterisk 13, we introduced two new features, the PJSIP channel driver
> and the sorcery configuration management tool, that have both made the
> stability and reliability of Asterisk better. However, when it comes to
> realtime configuration with ODBC, we've noticed that there is a bad trend
> of contention within res_odbc in Asterisk. This is because the PJSIP
> channel driver, unlike chan_sip, is multithreaded, meaning that multiple
> threads may be attempting to read or alter the database at the same time.
> Also, the use of sorcery, along with the use of different types of objects
> within the PJSIP channel driver, results in more database queries than were
> being performed with chan_sip.
>
> Part of this issue has been addressed by adding a memory cache to sorcery,
> and there will be work down the pipe to decrease the number of unneeded
> database queries. In the meantime, though, addressing the contention issue
> is something I want to get fixed.
>
> The big reason for the contention is that a default configuration of
> Asterisk results in a single connection to the database being created and
> shared between all threads. This connection is lock-protected, resulting in
> many threads potentially waiting on the lock in order to be able to use the
> connection. The res_odbc.conf file allows for an administrator to configure
> multiple connections for Asterisk to use, but this limitation is incredibly
> strict. If, for instance, you configure Asterisk to use five database
> connections, all five are in use, and a query is initiated, it will fail,
> rather than doing something graceful, like waiting for a connection to
> become available. Predicting the number of connections you'll need is
> incredibly difficult, and so you're likely to end up causing yourself big
> problems unless you set the limit to something absurdly high.
>
> The obvious solution to this problem is to use multiple database
> connections by default in Asterisk. One provision provided by unixODBC is a
> connection pooling option that can be enabled in odbcinst.ini. With this,
> any time that a connection is requested, it is pulled from a pool of
> connections. When disconnected, rather than being freed, the connection is
> added back to the pool. unixODBC has configuration options that allow for
> connections in the pool to eventually time out if they haven't been used in
> a while, and it has an option to allow for the connection to only be used a
> certain number of times before it is freed.
>
> The nice thing about this is that the connection pooling logic is provided
> completely under the hood, meaning all Asterisk ever has to do is request a
> connection and then disconnect it. A huge swath of code in res_odbc could
> be outright removed. There are two potential problems, though:
>
> * There is no way for us to enforce the use of connection pooling from our
> code. If connection pooling is not configured in odbcinst.ini, then
> Asterisk would end up creating and freeing database connections for each
> query, which could be costly in terms of performance (though admittedly it
> may still be better than the current situation).
> * The amount of data out there about connection pools is pretty limited. I
> had to figure out how it worked and what options were available from
> reading the unixODBC source code. More importantly, I don't have much data
> on the reliability/reputation of unixODBC connection pooling.
>
> I'm curious what opinions people have about what would be best for
> Asterisk with regards to using multiple ODBC connections. Do you have any
> experience using unixODBC connection pooling? Was the experience positive?
> Was the performance difference between using connection pooling vs. not
> using connection pooling noticeable?
>
> The alternative to using the connection pooling built into unixODBC would
> be to modify what currently exists in Asterisk to be less strict. The goal
> would be to work similar to how unixODBC works, in that multiple
> connections can be in use, connections can be re-used, and the limit on the
> number of open connections is "softer" 

Re: [asterisk-dev] [Code Review] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers

[Brad Watkins]

This is definitely the approach that I would prefer as well, as it
makes integration with external software much easier.

- Brad

On Thu, Apr 16, 2015 at 12:37 PM, Jeffrey Ollie j...@ocjtech.us wrote:
 On Wed, Apr 15, 2015 at 2:11 PM, Mark Michelson mmichel...@digium.com
 wrote:

 On 04/14/2015 12:11 PM, Matthew Jordan wrote:


 The question is: is this change worth having, or should it be scrapped
 in favour of some alternate approach that makes use of other
 technology? My feelings won't be hurt if the answer is ditch it and
 do something else - this was a fun piece of code to right on some
 plane flights. On the other hand, I don't have any real interest in
 writing an alternative approach, so if the expectation is that an
 AstDB wrapper around RabbitMQ or Redis will magically appear if I hit
 the delete key, that expectation is likely to be wrong.


 Personally, I like the idea of either

 2) Allowing the AstDB to use a remote key-value store, thus allowing
 multiple Asterisk boxes to share the same store.


 I think that it would be best to develop an interface to third-party
 key-value stores and let them handle the hard bits.  Personally, I like
 CoreOS' etcd, but there are others that could be useful like ZooKeeper,
 Consul or Redis.

 --
 Jeff Ollie


 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] DNS Support in Asterisk

[Brad Watkins]

Looking at this, I'm inclined to say that libunbound is the better of
the two options in spite of it being somewhat more difficult to
consume DNS records than it would be with c-ares.  In my estimation a
(seemingly?) more-active community and the inclusion of a cache are
more important.  DNSSEC isn't a huge deal, at least not for me at this
time, but is a nice bonus as well.

- Brad

On Thu, Feb 12, 2015 at 10:01 AM, Joshua Colp jc...@digium.com wrote:
 Greetings all,

 I've extended the sections of my wiki page for c-ares[1] and libunbound[2]
 to include further information about documentation, general usage
 experience, and other aspects. Personally I lean towards libunbound because
 it was straight forward to experiment with, supports DNSSEC, and has a
 cache.

 Cheers,

 [1]
 https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-c-ares
 [2]
 https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-libunbound


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

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

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)

[Brad Watkins]

On Thu, Oct 30, 2014 at 4:57 PM, Paul Albrecht palbre...@glccom.com wrote:


 On Oct 29, 2014, at 2:45 PM, Ben Klang bkl...@mojolingo.com wrote:


 On 10/28/2014 06:03 PM, Ben Langfeld wrote:

 On 28 October 2014 19:47, Derek Andrew derek.and...@usask.ca wrote:

 What is the alternative to the dial plan? Is everyone talking about getting 
 rid of the statements like:
 exten = s,1,

 what is the alternative?


 Remote applications based on APIs like ARI. This is the start of the 
 discussion, and please remember that nothing has been decided or even 
 presented as a robust plan yet. This is brain-storming.

 Additionally, note that the original proposal was to deprecate AMI/AGI in 
 favour of ARI once it is feature complete with those protocols; an entirely 
 lesser change than the removal of the dialplan in its entirety.



 Since this thread has my name on it, I guess it’s past time that I explain my 
 motivation for making the suggestion, and try to restore some of the context 
 that was present in the discussion at AstriDevCon.

 Before I jump into the details of my proposal, I’d like to clarify terms...


 It’s intellectually dishonest to redefine the terms of an argument to 
 presuppose your own conclusion. If you don’t intend to use the term 
 “deprecate” as it is commonly understood by software developers and users 
 than you should avoid the use of the term “deprecate” so that others clearly 
 understand your argument. If you really mean “deprecate” as commonly 
 understood by software developers and users then you should be prepared to 
 defend that proposition.

Ben's use of the term 'deprecate' aligns completely with my
understanding in addition to the definition provided on Wikipedia.  To
quote:  While a deprecated software feature remains in the software,
its use may raise warning messages recommending alternative practices;
deprecated status may also indicate the feature will be removed in the
future. Features are deprecated rather than immediately removed, to
provide backward compatibility and give programmers time to bring
affected code into compliance with the new standard.




 Now, on to what I originally proposed...


 It’s clear from the title of the agenda item what was proposed. You proposed 
 deprecating AMI/AGI and that entails deprecating the dial plan. The fact that 
 deprecating the dial plan is now on the table is a direct consequence of your 
 proposal. This is reflected in both comments made at AstiCon and Matt’s 
 summary of  Astricon on the development list. You can’t have it both ways. 
 You want to deprecate dial plan or not. Which is it?


It stretches credulity that you assert you can divine the intentions
of Ben or any of the others at AstriDevCon based solely on a
hastily-jotted note while we were brainstorming.  You cannot, and Ben
has chimed in with a very well-reasoned description of what he meant.

Additionally, there is absolutely NOTHING about the deprecation (or,
possibly, the eventual removal) of AMI/AGI that by its nature means
the dialplan is/will be/should be deprecated as well.  While there are
possible interactions amongst these three things, they are in large
part orthogonal.  As someone who was *actually there*, I can also
state that Leif's mention of 'moving away from dialplan' is merely a
statement of where he sees his development of Asterisk-based
applications going.  Tying these things together inextricably as you
have is a factually-unsupportable position.

 It is my opinion that while AGI and AMI are probably individually fixable, 
 doing so would cause backward-incompatible changes…


 Deprecating the dial plan and AGI/AMI is incompatible going forward. What is 
 supposed to happen? Are users supposed to throw away there applications 
 whenever ARI/Stasis is feature complete? Is ARI/Stasis really any easier to 
 use than the dial plan? Are we all supposed to use Adhearsion?

I don't recall Ben ever claiming (in the context of this discussion at
least) that anyone, much less everyone, should use Adhearsion.  I also
don't know that I've heard anybody claim ARI is easier (or harder!) to
use than dialplan.  What it does offer is a way of controlling
Asterisk that is different and in many ways more powerful than what's
possible today using any or all of dialplan/AGI/ARI.




 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] PJSIP Configuration Wizard (Was: Opinions Needed: PJSIP Outboud Registration with multiple server_uris)

[Brad Watkins]

As we talked about in #asterisk-dev, I like the proposal generally and
prefer the second style specifically.  Just as a matter of eventual
documentation, it'd be nice to see examples using a hierarchy of templates
that shows how to minimize duplication of configuration.

- Brad

On Wed, Oct 1, 2014 at 8:54 PM, George Joseph george.jos...@fairview5.com
wrote:

 This is a followup to the discussion we had in this thread...
 Opinions Needed: PJSIP Outboud Registration with multiple server_uris
 http://lists.digium.com/pipermail/asterisk-dev/2014-September/070426.html

 I started with wanting to allow multiple server_uris in a single
 registration object but where we wound up was with the creation of a new
 module that would provide a configuration layer on top of the existing
 pjsip configuration mechanism.  The purpose of the layer is to make
 configuration of the most common pjsip scenarios, and the transition from
 chan_sip, easier.  As a happy side effect, it also allows easier
 manipulation of pjsip contifuration from scripts  and AMI.

 Basically,  the new module creates a 'wizard' object that lets you
 configure common scenarios like 'phone' and 'trunk'  with a single object
 rather than defining a separate endpoint, aor, identify, auth,
 registration, etc.   It does NOT replace or alter the existing object
 model.  The wizard in fact just creates all the normal objects behind the
 scenes.

 Showing examples will be much easier than trying to describe it.

 PJSIP Configuration Wizard Proposal 1
 https://gist.github.com/gtjoseph/f11e1cdf261d93ef5516#file-pjsip_wizard_1-conf
 PJSIP Configuration Wizard Proposal 2
 https://gist.github.com/gtjoseph/e09978f8085091513115#file-pjsip_wizard_2-conf

 The difference between the 2 proposals is that the first one actually
 defines types called 'trunk', 'phone', and 'phone-static' which are used
 later in the config.   After staring at it a while though I thought there's
 really no benefit to the types if you use templates.  Hence the second
 proposal which I favor.  To see the real benefit of the whole approach,
 look down at sections starting at [myitsp].

 I know there are going to be questions and controversy so fire away!

 george










 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris

[Brad Watkins]

I'm just throwing this out there, but what if the pattern (we'll use that
name for now, although I'm not sure I like it as the final name) could
itself define new types.  Then, if you provided a standard config (i.e.,
the sample config) which defined some set of standard types (phone,
itsp/trunk, whatever) you could have configurations with semantics similar
to what Josh originally proposed.  It also means a user of Asterisk can
look at the config for the pattern and both see what it's doing under the
hood (vs. being in the code somewhere) and also modify it for their own
needs if they'd like to.

Anyway, just a thought.


On Sat, Sep 20, 2014 at 8:13 PM, George Joseph george.jos...@fairview5.com
wrote:

 On Sat, Sep 20, 2014 at 4:44 PM, Joshua Colp jc...@digium.com wrote:

 George Joseph wrote:

 snip



 How about we use the pattern approach but compile in patterns for trunk
 and user.  There are lots of minor differences between ITSPs and phones
 and I just worry that in the quest to create something for everyone we
 create something that's useful to no one.


 If it does not impact any of the existing code and is easy for a user,
 then sure. That being said... get feedback any way you can before doing
 anything. This is a complicated area.


 Unfortunately, it looks like everyone took Saturday off.   What gives?
  :)


 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] [Code Review] 3417: Add AMI events for all device state and presence state changes

[Brad Watkins]

On Mon, 2014-04-07 at 15:40 +, Mark Michelson wrote:
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3417/ 
 
 On April 5th, 2014, 7:02 a.m. UTC, Olle E Johansson wrote:
 
 I would like to see a configuration option for this, as it 
 will generate a massive amount of events in busy servers.
 That's fair. I can think of two ways to do this:
 
 1) The DeviceStateChange and PublishStateChange belong to a new event 
 category. This way, you can add the event category to your read= line in 
 manager.conf if you want to see the event, or you can leave the category off 
 if you don't.
 2) There can be individual configuration options in manager.conf to suppress 
 certain events. This would act as a generic method to disable the publication 
 of certain events and could be applied to any event.
 
 Personally, I like number 2 more, but I'm willing to hear suggestions for 
 other ways of doing this.
 
 
 
Regarding option 2, would that be per-user or global?  Either way that
too would be my preference, but curious how you saw that being
implemented.

- Brad

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Second thoughts on proposed MWI behavior change in Asterisk 12

[Brad Watkins]

On Thu, 2014-02-20 at 09:29 -0600, Mark Michelson wrote:

 What do you folks think? Should the code in the referenced review be the 
 proper way to handle things or is the idea proposed in this message a 
 better idea?
 
 Mark Michelson
 

I absolutely think the idea proposed here is better.  My opinion is that
indeed any configuration with unsolicited MWI configured should reject
subsription attempts.

- Brad
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Second thoughts on proposed MWI behavior change in Asterisk 12

[Brad Watkins]

On Thu, 2014-02-20 at 13:35 -0600, Mark Michelson wrote:
  
  George Joseph
  Thursday, February 20, 2014 9:47 AM
  snip
  
  
  With my user hat on, I think this is fair.  What would the
  subscription rejection look like?
 Since the issue doesn't lie with the SUBSCRIBE itself but rather with
 server configuration, a 500 response seems appropriate. There would
 also be an error message logged to indicate more specifically what
 went wrong (Think something like Subscription to mailbox 'foo'
 rejected since endpoint 'bar' is already receiving notifications).

For clarity I'd like to see the error message be more explicit about
*why* the endpoint is already receiving notifications.

- Brad
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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