VoIP Mailing List Archives

[cstomi.levlist at gmai...]

Hello,

we have a strange problem, sometimes calls are hung up with
DESTINATION_OUT_OF_ORDER cause.
I added some extra log lines, and it turned out that

switch_ivr_bridge.c:140 a timeout occurs while waiting for CF_BRIDGED flag
switch_channel_wait_for_flag(chan_b, CF_BRIDGED, SWITCH_TRUE, 10000,
chan_a); returns SWITCH_STATUS_TIMEOUT

As far as I understand the flag on B channel is set in another thread,
so maybe it happens slow sometimes.
We are using r14144. I know it is quiet old, but maybe this code hasn't
changed since them

Do you have any idea, what could cause this?
Do you think it is a bug?

Thanks in advance,
Tamas


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[anthony.minessale at g...]

10 seconds is a pretty long time for the 2nd half of the bridge to start?
You can try increasing it but you probably have a more profound problem if you are hitting that code.

When you start the bridge the code has 2 session pointers, it sets up state handler on the b leg and changes state to
get it to execute the audio bridge thread then it executes the same thread on the a leg so you end up with
2 sessions running audio_bridge_thread on each other.

Each leg thread uses that timeout you mentioned to make sure it's not waiting forever for the bridge to start in case something
happens to the other one.

You should follow what each leg is doing and find out why the other one did not make it into audio bridge thread.

It may be not answered or some other pre-conditon for thread. (are you uuid_bridging 2 channels where neither one is answered yet?)


On Fri, Aug 28, 2009 at 5:59 AM, Tamas Cseke <cstomi.levlist@gmail.com (cstomi.levlist@gmail.com)> wrote: