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_lists@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 mrene@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