[Freeswitch-dev] Bridge problem...
Anthony Minessale
anthony.minessale at gmail.com
Tue Jul 14 10:08:37 PDT 2009
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090714/60428255/attachment.html
More information about the Freeswitch-dev
mailing list