Heath Schultz wrote:
Howdy,
This is a solicitation for testers for the following
new app...
http://bugs.digium.com/view.php?id=5841
It allows you to bridge to another channel by name in
the dialplan.
Sounds interesting.
I'm looking a method to implement call waiting feature
in a device and
I'm so SORRY that I forgot to change the subject of my previous email.
Chih-Wei Huang wrote:
I'm trying the new application MixMonitor in 1.2-beta2.
Unfortunately, it didn't work as I expected.
My dialplan is like this:
[macro-checkrec]
;
; ${ARG1} - Caller
; ${ARG2} - Call
argument(filename).
That is, change the syntax to
MixMonitor([|[|[|]]])
Since MixMonitor is a very new application, it won't affect too many
people. I hope.
BTW, I'm curious why ${UNIQUEID} contains a dot.
It usually causes troubles. Doesn't it?
How about change it to _ (un
0,2,Pickup(90)
Apparently it doesn't work.
Can someone provide an example to explain how it works?
--
~ Chih-Wei Huang ([EMAIL PROTECTED])
'v'CTO, Citron Network Inc. ( http://www.citron.com.tw/ )
// \\ GnuGK Project : http://www.gnugk.org/(Develo
I found other strange delay audio in some situations:
* By enable courtesytone = beep in features.conf, the one who picks up
the parked call feels delay audio, about one second.
But without the beep, there is no sensible delay.
* Under attended transfer: A call B, B transfer to C, B hung up.
C he
Patrick wrote:
>
> Yes you need USE_RTC for better timing. And you maybe need kernel 2.6.13
> to get the USE_RTC functionality because it depends on the kernel. My
> FC4 box has a 2.6.12 kernel which contains the upstream USE_RTC stuff so
> I patch the asterisk source to enable it on 2.6.12 too. I
Tzafrir Cohen wrote:
On Mon, Oct 17, 2005 at 07:53:55AM -0400, BJ Weschke wrote:
Chih,
The bug was closed because the ztdummy behavior is not the specific cause
for the delay problem. That patch with USE_RTC was intended to make use of
the real time resource available within the kernel >= 2.6.1
l the macro by
exten => 111,1,Macro(conf)
Do you mean the options will affect the delay problem?
I'll try other options later...
On 10/18/05, Chih-Wei Huang <[EMAIL PROTECTED]> wrote:
BJ Weschke wrote:
The bug was closed because the ztdummy behavior is not the specific
caus
Since the bug has been closed, I sent the question here.
I saw patch for bug 4301 has been included in zaptel 1.2-beta1,
but with a limitation kernel version >= 2.6.13.
Does it mean USE_RTC will not work for kernel version < 2.6.13?
I tested meetme with OH323 driver and encountered the increasin
Hi,
Recently I have tried the chan_woomera by Anthony.
Basically speaking, I have it work (for incoming call, at least).
Next step, I tried to use G.723.1 codec. But there are problems.
The codec is negotiated and the call is connected,
but the sound is totally noise.
I have spent time to read wo
nnected.
I guess we can have Asterisk to adjust the read/writeformat of channels
when received early media packets to allow the early media be passed
back to A, just like the call be answered.
But I don't know how to do that.
(I know how to detect early media packets in Openh323,
but I don&
hope someone can point me a direction to solve
the problem.
PS. Both A and B use G.723.1 as the codec. I also installed
Intel IPP G.723.1 codec to Asterisk.
The problem disappears if I
* turn off the early media of B
* or, set G.723.1 as the only allowed codec in h323.conf
--
~ Chih-Wei
an guess what you concern.
You are afraid Openh323 been changed in future
so that my implementation will be broken?
--
~ Chih-Wei Huang ([EMAIL PROTECTED])
'v'CTO, Citron Network Inc. ( http://www.citron.com.tw/ )
// \\ GnuGK Project : http://www.gnugk.org/(Devel
OG_DEBUG, "Sending RTP 'US' %s:%d\n", info->addr,
info->port);
+ ast_rtp_get_us(pvt->rtp, &info->rtp_addr);
+ info->rtp_addr.sin_addr = bindaddr.sin_addr; /* hmm... do we
need this? */
return info;
}
--
~ Chih-Wei Huang ([EM
14 matches
Mail list logo
