On Tuesday 27 November 2007 15:11:14 Kevin P. Fleming wrote:
> This makes no sense; once chan_sip has fed you a frame of audio data,
> why should it care who frees it, and more importantly, how could it
> possibly know that the frame is no longer needed?
This is getting me very confused. Isn't it
From: "Kevin P. Fleming" <[EMAIL PROTECTED]>
> Sergio Garcia Murillo wrote:
>
> > I agree, but I think that it's a usually a good practice that the one
that
> > allocates
> > the memory is the reponsible of freeing it. What I don't really see is
why
> > the
> > apps need to call the ast_frfree on
Sergio Garcia Murillo wrote:
> I agree, but I think that it's a usually a good practice that the one that
> allocates
> the memory is the reponsible of freeing it. What I don't really see is why
> the
> apps need to call the ast_frfree on frames they have just readen.
This makes no sense; once ch
The Asterisk.org development team has announced the release of Zaptel
versions 1.2.22 and 1.4.7. These releases contain (among other things)
many bug fixes to the TC400B driver, a bug fix on the wctdm24xxp driver
for users with a VPM150M, as well as numerous improvements and fixes to
the Xorcom
From: "Kevin P. Fleming" <[EMAIL PROTECTED]>
> Sergio Garcia Murillo wrote:
>
> > So if you're writting a custom application you have to take care for
> > deleting the
> > frames you write and the frames you read, but if you write a custom
channel
> > you
> > don't have to worry?
> > Shouldn't be b
Tzafrir Cohen wrote:
> On Tue, Nov 27, 2007 at 11:06:19AM -0600, Russell Bryant wrote:
>> Eliel Sardanons wrote:
>>> We could start a janitor for creating a 'foo reload' and we could make
>>> de 'module reload *.so' do a module unload; module load
>> I would rather not change the behavior of "modul
Tilghman Lesher wrote:
> On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote:
>> - Remove the 'reload()' handler function on every module.
>
> I wouldn't do this last one. That is the handler that is called when we do
> a generic 'reload', for every single module.
Ah, good catch. Agreed
Hi,
Your ATAs are buggy or do not handle / pass progress in band
information properly. Unfortunately, there isn't much you can do.
Flash the firmware pehaps?
2007/11/27, robert santos <[EMAIL PROTECTED]>:
> gud day,
>
> hope this is not OT. currently encountering problem with ATA FXO FAS problem
Sergio Garcia Murillo wrote:
> So if you're writting a custom application you have to take care for
> deleting the
> frames you write and the frames you read, but if you write a custom channel
> you
> don't have to worry?
> Shouldn't be better to have a general policy about it, for example the one
- Original Message -
From: "Russell Bryant" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List"
Sent: Tuesday, November 27, 2007 5:17 PM
Subject: Re: [asterisk-dev] ast_frame allocation/free question
> Sergio Garcia Murillo wrote:
> > I've been trying to fix some memory leaks in
Tilghman Lesher wrote:
> On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote:
>
>> On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote:
>>
>>> Eliel Sardanons wrote:
>>>
We could start a janitor for creating a 'foo reload' and we could make
de 'module reload *.so'
On Tue, Nov 27, 2007 at 11:06:19AM -0600, Russell Bryant wrote:
> Eliel Sardanons wrote:
> > We could start a janitor for creating a 'foo reload' and we could make
> > de 'module reload *.so' do a module unload; module load
>
> I would rather not change the behavior of "module reload". I think th
On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote:
> On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote:
> > Eliel Sardanons wrote:
> > > We could start a janitor for creating a 'foo reload' and we could make
> > > de 'module reload *.so' do a module unload; module load
> >
> > I would
- Original Message -
From: Simon Perreault
[mailto:[EMAIL PROTECTED]
To: asterisk-dev@lists.digium.com
Sent:
Tue, 27 Nov 2007 13:06:36 -0400
Subject: Re: [asterisk-dev]
[asterisk-commits] file: trunk r89637 - /trunk/main/utils.c
> On Tuesday 27 November 2007 12:01:19 SVN commits to the As
So:
- Start a janitor to implement 'foo reload' for every module that does
something in the reload() handler function.
- Deprecate CLI command 'module reload '
- Remove the 'reload()' handler function on every module.
Eliel
On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote:
> Eliel Sardanons
On Tuesday 27 November 2007 12:01:19 SVN commits to the Asterisk project
wrote:
> + long int rm = RAND_MAX;
> res = res < 0 ? ~res : res;
> - return res;
> + rm++;
> + return res % rm;
Hum... Won
Eliel Sardanons wrote:
> We could start a janitor for creating a 'foo reload' and we could make
> de 'module reload *.so' do a module unload; module load
I would rather not change the behavior of "module reload". I think that would
be much worse than just removing it, as it changes behavior that
I agree with the idea of starting a new Janitor to update the modules to use
' reload' and change the behaviour of module reload to unload and
load the module. This way, ' reload' should reparse the
configuration file and 'module reload' should unload and load the module.
Also, I think this should
18 matches
Mail list logo
