Some more detail..
This is in the 1.0.9 release, btw..
I'm looking through channel.c. When the timeouts are occurring early, the
following statement in ast_channel_bridge is evaluating to true, which
triggers the native bridge:
if (c0->pvt->bridge && config->timelimit==0 &&
(c0->pvt->bridge == c1->pvt->bridge) &&
!nativefailed && !c0->monitor && !c1->monitor) {
However, (config->timeout == 0) should never evaluate to true, since I'm
setting a timelimit when using the Dial command.
I've added debug statements to check the config->timelimit at the beginning
of the ast_channel_bridge, and it evaluates to the correct value. I've been
testing with config->timelimt=3600000.
It doesn't look like anything should modify the value set there. I've tried
adding more debug statements, but I can't find anything that's modifying the
timelimit value.
Peter
----- Original Message -----
From: "Peter Hsu" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
Sent: Friday, July 22, 2005 12:50 PM
Subject: Re: [Asterisk-Dev] Disabling native bridging altogether?
Hmm,
It seems it was different issue altogether.
It looks like if I use the L() feature, the timeout seems to occassionally
expire prematurely.
When the timeout expires, asterisk will attempt the native bridging, which
is why I thought native bridging was causing the problems.
However, I can't seem to track down what is causing the timeout value to
get set to 0.
It seems random, occurring maybe 20% of the time.. Has anyone else seen
anything like this? I didn't see any bugs directly related to this, but
maybe bug 0004504 applies?
Peter
----- Original Message -----
From: "mattf" <[EMAIL PROTECTED]>
To: "'Asterisk Developers Mailing List'" <asterisk-dev@lists.digium.com>
Sent: Thursday, July 21, 2005 8:10 PM
Subject: RE: [Asterisk-Dev] Disabling native bridging altogether?
There are other issues with native bridging that would warrant a Dial
flag
to disable them at least per dial. For instance, two natively bridged Zap
channels cannot be recorded(only records one side of the audio). One
current
way to disable native bridging upon Dial is to add the 't' flag, of
course
that also opens up the ability to transfer out of the call which is
sometimes undesireable, but it is a workaround that does work on all
types
of channels.
MATT---
-----Original Message-----
From: Peter Hsu [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 21, 2005 8:27 PM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] Disabling native bridging altogether?
Gary,
Not sure how that would help...
The issue occurs when the extension is not busy, and the call is
transferred. The native transferring is being done when I don't want it
to
be done.
Peter
----- Original Message -----
From: "Gary" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
Sent: Thursday, July 21, 2005 4:25 PM
Subject: Re: [Asterisk-Dev] Disabling native bridging altogether?
why not simply if extension busy go play a message and wait 30 seconds
and jump back to ring again, if busy ......
On Thu, 21 Jul 2005 14:35:09 -0700, Peter Hsu wrote:
Thanks for the response.
Essentially, I want asterisk to pause execution of the dialplan until
after
the called party hangs up.
It seems if the native bridging occurs, execution of the diaplan
continues
immediately.
Maybe I'm barking up the wrong tree?
Thanks,
Peter Hsu
----- Original Message -----
From: "Kevin P. Fleming" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
Sent: Thursday, July 21, 2005 1:40 PM
Subject: Re: [Asterisk-Dev] Disabling native bridging altogether?
Peter Hsu wrote:
My asterisk server seems to be sporadically attempting native
transfers
when I don't expect it to. I've set notransfer=yes in my iax.conf
both
in the general section and for each of my outgoing peers. I also
include
the t, T, and L(some int > 0) tags when doing the transfer.
You are confusing native bridging and native transfers (which are one
step
below).
Native bridging means it allows the channel driver (chan_iax2 in this
case) to handle the audio bridging, rather than sending the audio up
the
stack into the res_features bridge. This is more efficient, and using
'Tt'
will not stop it, since chan_iax2 can bridge the audio and still stop
bridging when DTMF arrives, since DTMF is always out of band in IAX2.
Native transfers are something else entirely (IAX2 specific), and
control
what will happen when one IAX2 peer calls another _through_ your box.
If
"notransfer" is not set, then your box will drop out of the path, and
allow the two IAX2 peers to talk directly to each other.
-- Stopped music on hold on Local/[EMAIL PROTECTED]
-- Attempting native bridge of IAX2/Gafachi-out/2 and
IAX2/Gafachi-out/1
Why don't you start by describing why you think you need to keep this
native bridge from happening, instead of finding ways to mangle the
code
involved...
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
.
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
