[Freeswitch-dev] conference vs. bridge
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 extension. If the new extension is answered, the callee is dumped into a menu system. This menu system tells them about the customer and lets them choose whether or not to connect with the customer. A bridge is created between the two legs and conversation happens. 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 back to the main menu. However, it seems that if either leg of the call hangs up, the bridge hangs up the other end. Is there a way around this using call bridging? Or, should I be looking into a more complex setup using mod_conference? Currently, I am using uuid_bridge to setup the bridge, in case you need to know that. Thanks in advance for any advice. Cheers. Kevin
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 back to the main menu. However, it seems that if either leg of the call hangs up, the bridge hangs up the other end. Is there a way around this using call bridging? Or, should I be looking into a more complex setup using mod_conference? Currently, I am using uuid_bridge to setup the bridge, in case you need to know that.
http://wiki.freeswitch.org/wiki/Channel_Variables#hangup_after_bridge Should take care of that make sure you set it on the leg you want to continue after the bridge is complete.
Thanks in advance for any advice.
Cheers. Kevin
transfer_after_bridge is probably even more useful On Mon, Jul 13, 2009 at 4:40 PM, Brian West <brian@freeswitch.org> 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 bridging won't let me do what I want. Specifically, if the callee hangs up, I want to send the customer back to the main menu. However, it seems that if either leg of the call hangs up, the bridge hangs up the other end. Is there a way around this using call bridging? Or, should I be looking into a more complex setup using mod_conference? Currently, I am using uuid_bridge to setup the bridge, in case you need to know that.
http://wiki.freeswitch.org/wiki/Channel_Variables#hangup_after_bridge
Should take care of that make sure you set it on the leg you want to continue after the bridge is complete.
Thanks in advance for any advice.
Cheers. 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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
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 to switch_core_session_rwunlock() the session you got out of originate, FS uses reader-writer locks as a reference counting system for session structures, the session thread will do a write lock before freeing the memory. If your call doesn't disappear, you probably are missing that unlock (ivr_originate locks it before returning) 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:
switch_ivr_multi_threaded_bridge
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
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
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 mrene@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_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
_______________________________________________ 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
OK, thanks. I¹ll look at how mod_commands handles this. Also, I just realized that the problem is not that my handlers are not called but that the hangup isn¹t happening. After everybody has literally hung up, using ³show channels² still shows those two channels as active. They haven¹t hung up yet. Using ³hupall² and they hang up with my handlers being called. Somehow, the legs that I originate aren¹t figuring out that the ends they connect to have hungup. I am calling the switch_core_session_rwunlock after the bridge completes. Thanks again...I¹ll keep wrestling with it. Kevin On 7/14/09 9:24 AM, "Mathieu Rene" <mrene_lists@avgs.ca> wrote:
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 mrene@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_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
_______________________________________________ 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
is this a sip call? are possibly not getting the bye when you hangup? turn on sip trace and debug logging and hangup and watch for what happens On Tue, Jul 14, 2009 at 11:50 AM, Kevin Snow <kevin.snow@ooma.com> wrote:
OK, thanks. I’ll look at how mod_commands handles this.
Also, I just realized that the problem is not that my handlers are not called but that the hangup isn’t happening. After everybody has literally hung up, using “show channels” still shows those two channels as active. They haven’t hung up yet. Using “hupall” and they hang up with my handlers being called. Somehow, the legs that I originate aren’t figuring out that the ends they connect to have hungup.
I am calling the switch_core_session_rwunlock after the bridge completes.
Thanks again...I’ll keep wrestling with it.
Kevin
On 7/14/09 9:24 AM, "Mathieu Rene" <mrene_lists@avgs.ca> wrote:
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 mrene@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_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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Thanks for all of the pointers. exec_after_bridge_app=park is just the thing. Cheers. Kevin Anthony Minessale wrote:
transfer_after_bridge is probably even more useful
On Mon, Jul 13, 2009 at 4:40 PM, Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> 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 bridging > won't > let me do what I want. Specifically, if the callee hangs up, I want > to > send the customer back to the main menu. However, it seems that if > either leg of the call hangs up, the bridge hangs up the other end. > Is > there a way around this using call bridging? Or, should I be looking > into a more complex setup using mod_conference? Currently, I am > using > uuid_bridge to setup the bridge, in case you need to know that.
http://wiki.freeswitch.org/wiki/Channel_Variables#hangup_after_bridge
Should take care of that make sure you set it on the leg you want to continue after the bridge is complete.
> > Thanks in advance for any advice. > > Cheers. > Kevin
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org <mailto: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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ 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
participants (5)
-
Anthony Minessale
-
Brian West
-
Kevin Raison
-
Kevin Snow
-
Mathieu Rene