Try using an event hook on state hange instead of a state handler.
Or, if you don't need access to the session once its hung up, use a
plain event handler.
One thing you need to know about threads is that FS spaws its own
thread per call. You can do your own stuff in as many threads as you
want as long as you don't touch the media itself. Look at the source
of api commands in mod_commands and you'll see how they interact with
active calls.
Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mr...@avgs.ca
Am 14-Jul-09 um 11:47 AM schrieb Kevin Snow:
Thanks for your help on this, I’m getting closer but still have
something wrong.
I changed the code to use the bridge function you mentioned. It does
seem to work a little better as the multithreaded bridge sometimes
had audio glitches that this method doesn’t
const char* sessionUUID =
switch_core_session_get_uuid(session);
const char* peerSessionUUID =
switch_core_session_get_uuid(peer_session);
switch_status_t status = switch_ivr_uuid_bridge(sessionUUID,
peerSessionUUID);
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO,
"bridge_common - Bridge complete (%d)\n",(int)status);
int addHandlerOK =
switch_channel_add_state_handler
( switch_core_session_get_channel(peer_session),
&bridge_common_state_handlers);
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO, "+++++
++++++++++++++++++++++++++++++++++++++++++++ ADDED HANDLER OK %d
\n",addHandlerOK);
This bridges fine and the call is working. The
switch_ivr_uuid_bridge function returns immediately where the other
blocked. I’m adding the handler back in and
switch_channel_add_state_handler is returning a 1, which I seems OK.
static switch_status_t my_hangup(switch_core_session_t *session)
{
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_INFO,
"======================= HANGUP CALLED ============================
\n");
return SWITCH_STATUS_SUCCESS;
}
static const switch_state_handler_table_t
bridge_common_state_handlers =
{
/*.on_init */ NULL,
/*.on_routing */ NULL,
/*.on_execute */ NULL,
/*.on_hangup */ my_hangup,
/*.on_exchange_media */ NULL,
/*.on_soft_execute */ NULL
};
Not sure why but when the peer_session leg is hung up my_hangup
routine is not called.
One thing I should mention is that I’m originating these legs and
bridging on a thread that I started. I believe that is somehow part
of the problem. The situation I have is that a handset is picked up.
I collect the digits dialed, when this is complete I’m creating a
thread (this thread above) and having it create a leg to the number
dialed and another known endpoint. I’m doing it on another thread
because I want that handset to be able to hang up but leave this
call in place. I am getting my hangup called on the handset (it’s
not this above handler, it’s a different one I didn’t show you). If
I leave the new thread out of this and just bridge the handset to
the dialed number, I do get hangup called for both.
Clearly, there is something I’m not understanding and have wrong here.
Any ideas?
Thanks in advance.
Kevin
On 7/13/09 3:59 PM, "Mathieu Rene" <mrene_li...@avgs.ca> wrote:
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.
Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mr...@avgs.ca
On 13-Jul-09, at 6:20 PM, Kevin Snow wrote:
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 to be able to pass
a DTMF callback.
In any case, the above is working fine. My problem comes in when
one of the ends hangsup, it’s not exiting the bridge function.
It’s like the calls are still bridged (because I think they are).
Running “show channels”, does in fact, show the two legs sitting
there. Using the “hupall” command, does hang them up, handlers
called and my world then shutsdown.
I’m not sure what I have wrong here. Is there something special I
need to do to detect when an endpoint hangup?
Thanks
Kevin
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-
dev
http://www.freeswitch.org
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
