[Freeswitch-dev] Bridge problem...

Kevin Snow kevin.snow at ooma.com
Tue Jul 14 09:50:55 PDT 2009 

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090714/5196d2b0/attachment-0001.html

More information about the Freeswitch-dev mailing list