On 12/06/2007, at 21:13, George Williams wrote:
I am wondering if there are software telephony tools that might
help me
automate the testing of the asterisk-related features. Some kind of
scripting interface would be ideal and open-source, as well.
What exact kind of asterisk-related feature
On 12/06/2007, at 16:57, Russell Bryant wrote:
ast_debug(3, ...);
Shouldn't this be ast_debug(4, ...) since ast_debug(level, ...)
checks
for option_debug >= level?
Yes, you are right. Please excuse my poor example. :)
Ops! So we made tons of changes with the wrong level sequence? :-(
I
Hi,
Asterisk is an important component of the telephony product that I work on.
I am wondering if there are software telephony tools that might help me
automate the testing of the asterisk-related features. Some kind of
scripting interface would be ideal and open-source, as well.
Does anyone
since i see a lot of activities regarding this, i'd like to point to:
http://bugs.digium.com/view.php?id=8849
I think that was a good way to increment the functionality of ast_log (and
eventually, ast_verbose).
On 6/12/07, Michiel van Baak <[EMAIL PROTECTED]> wrote:
On 11:18, Tue 12 Jun 07, R
On 11:18, Tue 12 Jun 07, Russell Bryant wrote:
> Dmitry Andrianov has created a new macro, ast_debug() which simplifies
> debug logging. He has also converted main/pbx.c to use it. Now, the
> rest of the code base needs to get converted. If you are interested in
> helping, volunteer to take a
Steven Critchfield wrote:
Problem I ran into, and maybe it doesn't need any changes is that the
res_eventtest.c doesn't test option_debug before logging to debug. So
when converted, it failed since it didn't know of option_debug. This is
the only file I didn't submit a patch for as it would break
Tzafrir Cohen wrote:
> Is it really needed? Why should it be installed by default?
> (BINS are instaleld by default, right?)
As far as I am aware it has only one purpose: to help the user find out
if loading Zaptel and card drivers is having a measurable impact on
their system performance. I don'
Tzafrir Cohen wrote:
> Is ethdlc-new actually being used "in the wild"? sethdlc?
Yes, sethdlc-new is the only tool that has ever worked for me to setup
an HDLC link.
> Rename sethdlc-new to sethdlc in trunk and sethdlc to ssethdlc-24 in
> trunk?
I would just remove sethdlc in trunk and rename s
On Tue, 2007-06-12 at 15:55 -0500, Steven Critchfield wrote:
> On Tue, 2007-06-12 at 16:58 -0300, Caio Begotti wrote:
> > On 12/06/2007, at 13:52, Michiel van Baak wrote:
> > > chan_skinny is now being worked on by me :)
> >
> > I working on the following 4 applications:
> >
> > app_queue.c: 45
>
On 6/12/07, Steve Murphy <[EMAIL PROTECTED]> wrote:
I have created an asterisk.org blog entry:
http://www.asterisk.org/node/48358
to describe what I will shortly be committing to trunk to correct the
weaknesses of CDRs, that asterisk users and developers have been
complaining about for quite so
On Tue, 2007-06-12 at 21:54 +0200, Stephen Davies wrote:
> Steve,
>
> I've just updated my SVN trunk install to Revision: 67303
>
> I was previously running SVN trunk Revision 62263.
>
> Since the update, my CDR records have a nasty change:
>
> Previously, my CDRs were:
>
> "peer-pri-hetzner",
On 12/06/07, Stephen Davies <[EMAIL PROTECTED]> wrote:
Maybe just maybe another fix is that ast_cdr_init should also do the
S_OR(s->macrocontext, s->context) stuff that ast_cdr_update does.
Excuse me for talking to myself, but this does do the job.
Here's a patch:
Index: cdr.c
==
12 matches
Mail list logo
