[asterisk-dev] Notes from SNMP breakout session

Jeff Gehlbach jeffg at jeffg.org
Wed May 23 14:14:20 MST 2007


Hi!

Some good discussion came from the SNMP breakout session this afternoon
at astridevcon.  The conversation moved quickly from "what to do with
SNMP / res_snmp" to the realization that a new layer / API is needed
within Asterisk to provide internal stats.  The reasoning behind this
thinking is that res_snmp is really the third component that needs to
get at lots of internal data.  The CLI and the manager are the others.

A new internal stats data API would become the place to go when you need
information on the system's behavior or performance.  It would be
somewhat like the event infrastructure that has come up in several
discussions this week at astridevcon, only it's for take-out whereas the
event stuff is for delivery.

The CLI, AMI, and res_snmp would all become customers of this API.
I think that the above comprise the full list of existing components
that should be customers.  Do any others come to mind?

Once the API customers are identified, the next step is to identify all
the data that must be exposed to serve these customers and to define a
generic way to represent the data internally.  Finally, the customer
components can be moved one piece at a time to the new API.

Concerns that came up in the breakout are the following:

* Making the internal data representation generic enough for any
  customer component to consume it -- what existing C-language projects
  exist from which we could draw inspiration (aka steal code) in this
  realm?
* Getting the API done and debugged in time for 1.6 will be "fun"
* Concurrency - the rest of Asterisk will be changing around and under
  those working on this project.  Doing the work in a branch will help,
  but awareness of this project in the developer community will be
  critical.  Hence this post :)
* Distributedness - same as with the new event stuff, the stats data API
  needs to be designed with an eye towards working (or at least being
  easily adapted) in a distributed installation.

Comments earnestly solicited!
-jeff


More information about the asterisk-dev mailing list