Re: [Freeswitch-dev] core dump with the latest build

2009-07-13 Thread Michael Jerris
What revision are you using? I have not seen any reports of this before. Can you try trunk and see if it persists and if so post a bug to jira.freeswitch.org. Mike On Jul 13, 2009, at 10:50 PM, Juan Backson wrote: > Hi, > > I am running FS with production traffic and when it reaches aro

[Freeswitch-dev] core dump with the latest build

2009-07-13 Thread Juan Backson
Hi, I am running FS with production traffic and when it reaches around 70cps on a Intel(R) Xeon(R) CPU E5520 @ 2.27GHz, I am getting a core dump ( as shown below ). This core dump has been happening multiple times in one day. Is this a problem with the latest trunk? If so, which build should

Re: [Freeswitch-dev] Bridge problem...

2009-07-13 Thread Mathieu Rene
On another note, switch_ivr_uuid_bridge() will flush the state handler table for both legs. You need to set them back after. Note that event hooks aren't removed, so you can use switch_core_event_hook_add_state_change() (look in mod_limit for an example) to get a callback on state change. M

Re: [Freeswitch-dev] Bridge problem...

2009-07-13 Thread Mathieu Rene
Kevin, You can't call that function directly, you need to tell the core to bridge the 2 channels together, or else you end up with 2 threads trying to do media on the same thread. Look at switch_ivr_uuid_bridge(const char *originator_uuid, const char *originatee_uuid); Also don't forget

[Freeswitch-dev] Bridge problem...

2009-07-13 Thread Kevin Snow
Hi, In my module (written in C) I spin up a session using the recipe you gave me a few weeks ago. I then use switch_ivr_originate twice to establish two endpoints and bridge them using switch_ivr_multi_threaded_bridge. I inherited some of this code, but I think it¹s using the multithreaded bridge

Re: [Freeswitch-dev] conference vs. bridge

2009-07-13 Thread Anthony Minessale
transfer_after_bridge is probably even more useful On Mon, Jul 13, 2009 at 4:40 PM, Brian West wrote: > > On Jul 13, 2009, at 4:37 PM, Kevin Raison wrote: > > > Now, all of this was easy, thanks to FreeSWITCH and mod_event_socket. > > However, I would like to add a feature, and I think that bri

Re: [Freeswitch-dev] conference vs. bridge

2009-07-13 Thread Brian West
On Jul 13, 2009, at 4:37 PM, Kevin Raison wrote: > Now, all of this was easy, thanks to FreeSWITCH and mod_event_socket. > However, I would like to add a feature, and I think that bridging > won't > let me do what I want. Specifically, if the callee hangs up, I want > to > send the customer

[Freeswitch-dev] conference vs. bridge

2009-07-13 Thread Kevin Raison
I am trying to figure out the best way to handle a business requirement set by a client for whom I am writing a custom IVR using FreeSWITCH. The situation is this: Customer calls in, navigates menus, selects a desired extension. Customer is parked, a new call is initiated to the desired extensio

Re: [Freeswitch-dev] access session variables after hangup

2009-07-13 Thread Michael Collins
On Mon, Jul 13, 2009 at 6:39 AM, rentmycoder rentmycoder < rentmyco...@gmail.com> wrote: > I don't care about billing, but do care about very detailed realtime > and historical call logging and routing system. Are you building something that monitors call status while the calls are still in prog

Re: [Freeswitch-dev] access session variables after hangup

2009-07-13 Thread Brian West
On Jul 13, 2009, at 8:39 AM, rentmycoder rentmycoder wrote: > I don't care about billing, but do care about very detailed realtime > and historical call logging and routing system. > xml cdr is not an option since it does not handle certain logging > scenarios like call transfers, multy party cal

[Freeswitch-dev] access session variables after hangup

2009-07-13 Thread rentmycoder rentmycoder
I don't care about billing, but do care about very detailed realtime and historical call logging and routing system. xml cdr is not an option since it does not handle certain logging scenarios like call transfers, multy party call conversions, custom call events like recording started or stopped, e