VoIP Mailing List Archives

[mgg at giagnocavo.net]

Which revision? Wasn't there some read-write lock issues on sessions checked in during the last week?

FWIW, we do inline billing, but the message queue timeouts are very low. Upgrading to current SVN kills us (~15025 works fine) -- some channels stay in CS_EXECUTE, some in CS_REPORTING. We know it's not our code blocking, because there'd be transaction timeouts within 30 seconds, and these are hanging around for a long time.

I suspect it's something with how we do our originates and state handlers. If we _overwrite_ the default originate handlers AND patch originate to blank out dialplan/context after duplicating the caller profile, it works fine. If we "do the right thing" and let the default handler set CS_CONSUME_MEDIA, then we get the calls hanging around forever. As I said, I suspect this is mismatch in what FS does and what our app assumes it does.

-Michael

-----Original Message-----
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Rupa Schomaker
Sent: Saturday, October 31, 2009 1:28 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Many CS_REPORTING state Zombie session

Nothing jumps out at me on this one.

mod_cdr_csv and/or mod_xml_cdr should be fine.

On Sat, Oct 31, 2009 at 1:24 PM, Seven Du <dujinfang@gmail.com> wrote:

[anthony.minessale at g...]

it something doing a read/write lock then not clearing it or its bad build and you have to rebuild clean.
the trace had no session threads present in it.
look in the code of any non-standard mods you are using for something that did either switch_ivr_originate or switch_core_session_locate and never called switch_core_session_rwunlock

#define SWITCH_DEBUG_RWLOCKS at the top of switch.h
and make clean ; make install to get rwlock debugging.


On Sat, Oct 31, 2009 at 3:00 PM, Michael Giagnocavo <mgg@giagnocavo.net (mgg@giagnocavo.net)> wrote:

[dome at tel.co.th]

Yes. i user api_hangup_hook for do callback.
<action application="set" data="api_hangup_hook=originate
{origination_caller_id_number=${caller_id_number},callback_uuid=${uuid},ignore_early_media=true}${route_1}|${route_2}|${route_3}
call_ivr${caller_id_number} XML public "/>

may be need originate_timeout

Dome C.


2009/11/1 Rupa Schomaker <rupa@rupa.com>:

[anthony.minessale at g...]

Use bgapi originate ...

[dome at tel.co.th]

How to use bgapi in my flow.
1. user call did
2. FS send ringing and check balance, LCR from DB (by mod_odbc_quey)
3. Hangup (by use or timeout)
4. FS callback to user and bridge to IVR

I'm not sure bgapi can do after channel hangup.

Dome C.


2009/11/1 Anthony Minessale <anthony.minessale@gmail.com>:

[anthony.minessale at g...]

#4 makes no sense to me.
Are you just trying to create a call that the channel does not participate in?
Then for sure you want to use bgapi to cause the originate to  happen in the background.

Also your gcore report has to be taken while you have the stuck channels to see why they are stuck.
I can promise you this problem should be filed under misuse/abuse.


On Sat, Oct 31, 2009 at 8:45 PM, Dome Charoenyost <dome@tel.co.th (dome@tel.co.th)> wrote:

[dome at tel.co.th]

2009/11/2 Anthony Minessale <anthony.minessale@gmail.com>:

[anthony.minessale at g...]

if you set the variable to:

"originate foo bar baz"

"bgapi originate foo bar baz"

bgapi is itself an api command that takes the argument string and runs it in a separate thread and returns instantly.
This will stop it from hanging at that point.




On Sun, Nov 1, 2009 at 1:53 PM, Dome Charoenyost <dome@tel.co.th (dome@tel.co.th)> wrote: