Tim Panton wrote:
> If I understand the issue right, we need to be able to re-negotiate the
> parameters mid-call (change the quality measure on a codec for example)
> not just at setup time.
That is only part of the issue; the more immediate problem is that we an
Asterisk 'format' encompasses th
JFYI:
I tried something similar to:
reqprep(&req, p, SIP_INFO, 0, 1);
sprintf(buf,
"%s;type=%s;charging-info=%s;currency=%s;amount=%lu;multiplier=%s",
"charging", "active", "currency", "EUR", amount, "0.001");
add_header(&req, "AOC", buf);
add_header_contentLength(&req, 0);
return send_request(p,
U are careless:), the ast_set_priority() also call some such functions.
On 4/6/07, Tilghman Lesher <[EMAIL PROTECTED]> wrote:
On Friday 06 April 2007, Yuan Qin wrote:
> The ast_log() will lock a mutex if appropriate, but the mutex may be in
> locked state already.
> Maybe we should use pthread_
On Friday 06 April 2007, Yuan Qin wrote:
> The ast_log() will lock a mutex if appropriate, but the mutex may be in
> locked state already.
> Maybe we should use pthread_atfork() instead of fork() or never call some
> functions that hold mutex
> before execv() in child process.
>
> Is there somethin
Yes, you are right, it's my mistake:) the pthread_atfork only register some
clean handler.
On 4/6/07, Kevin P. Fleming <[EMAIL PROTECTED]> wrote:
Yuan Qin wrote:
> The ast_log() will lock a mutex if appropriate, but the mutex may be in
> locked state already.
> Maybe we should use pthread_atf
On 6 Apr 2007, at 16:14, Kevin P. Fleming wrote:
Olle E Johansson wrote:
But what's the format of the attachment? Back to codec negotiation
again. I would call it "call properties negotiation"
because it is more than codecs - it will soon also become security
properties.
Given the importanc
Yuan Qin wrote:
> The ast_log() will lock a mutex if appropriate, but the mutex may be in
> locked state already.
> Maybe we should use pthread_atfork() instead of fork() or never call
> some functions that hold mutex
> before execv() in child process.
pthread_atfork() does not fork, it does some
Olle E Johansson wrote:
> But what's the format of the attachment? Back to codec negotiation
> again. I would call it "call properties negotiation"
> because it is more than codecs - it will soon also become security
> properties.
Given the importance and complexity of this issue, I am already ma
Hi, all
I found that code in res_agi.c(version of 1.2.13) called fork() to
create an AGI process,
however, fork() is not a safe function in Linux multi-thread environment
because the child
process only hold one thread that made from a copy of the calling thread but
inherit all the mutex
or co
[EMAIL PROTECTED] wrote:
> Modified: branches/1.4/formats/format_wav.c
> URL:
> http://svn.digium.com/view/asterisk/branches/1.4/formats/format_wav.c?view=diff&rev=60325&r1=60324&r2=60325
> ==
> --- branches/1.4/formats/f
-Issue 4825, "new codec negotiation algorithm" - Dwayne will review
the patch and summarize during the next couple of weeks
It's important to review the videocaps alternative too. It's
something that is tested and works very well for video and
could easily be extended to audio too.
We need
On Fri, 6 Apr 2007 10:32:24 +0800, Di-Shi Sun wrote
> Hi All,
>
> When I tried asterisk 1.4 downloaded from svn yesterday, I found the CDR
function did not work anymore after a call. After I readed the code, I found
the ast_bridge_call in res_feature.c caused this problem.
>
> In ast_bridg
12 matches
Mail list logo
