[Freeswitch-users] Question about using switch_caller_extension_add_application

[Mathieu Rene]

Hi,

You can set the "continue_on_fail" variable to true (or to the hangup  
causes you want it to ignore) and it'll keep executing whats queued.
For receive_message, unless you hook the session thats being created  
as a B-leg, you won't get anything relevant.
Also set hangup_after_bridge=true if you want to stop failing over  
when it worked.

Im curious, what are you coding? you can transfer the call in the  
dialplan without having to do all this manual queuing in C, thats why  
the routing state and dialplan modules exist. If you need to pull data  
from somewhere you can fill in channel variables that you can  
reference in the dialplan.

/*!
   \brief Transfer an existing session to another location
   \param session the session to transfer
   \param extension the new extension
   \param dialplan the new dialplan (OPTIONAL, may be NULL)
   \param context the new context (OPTIONAL, may be NULL)
*/
SWITCH_DECLARE(switch_status_t) switch_ivr_session_transfer(_In_  
switch_core_session_t *session, const char *extension, const char  
*dialplan,
															const char *context);



Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene at avgs.ca




Am 5-Aug-09 um 7:20 PM schrieb Woody Dickson:

> Hi,
>
> The problem is that I need freeswitch to continue executing the code  
> after switch_status_t channel_receive_message even when it gets  
> error SIP code from the destination.  Is that possible?
>
> I know if I set up another action after my module in the  
> dialplan.xml, I can catch that.
>
> But I would like the code to execute within the route that I have.   
> Is that doable?
>
> Woody
>
> On Thu, Aug 6, 2009 at 12:34 AM, Mathieu Rene <mrene_lists at avgs.ca>  
> wrote:
> The hangup cause will be in the originate_disposition channel  
> variable on the A-leg.
>
> sip_term_status will contain the sip code and  
> proto_specific_hangup_cause will contain sip:<code>.
>
>
> Mathieu Rene
> Avant-Garde Solutions Inc
> Office: + 1 (514) 664-1044 x100
> Cell: +1 (514) 664-1044 x200
> mrene at avgs.ca
>
>
>
>
> Am 5-Aug-09 um 11:23 AM schrieb João Mesquita:
>
>> My guess is that you will receive a message here:
>>
>> switch_status_t channel_receive_message(switch_core_session_t  
>> *session, switch_core_session_message_t *msg)
>>
>> The problem here is that you don't have the exact SIP code but  
>> there is a clear relationship between the codes and the messages  
>> you receive on the channel, so I am guessing that is all the same.
>>
>> Hope this helps.
>>
>> jmesquita
>>
>> On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson at gmail.com 
>> > wrote:
>> Hi,
>>
>> I want to implement a module where freeSWITCH would try to bridge  
>> to an extension and if the bridging operation fails, my module can  
>> use the hangup code to determine the next cause of action.
>>
>> With switch_caller_extension_add_application(session, extension,  
>> "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503  
>> received for instance ) in the outgoing INVITE, freeSWITCH would  
>> leave my module ( or the module's APP) and go on to the next  
>> action.  Is there anyway to control it so that freeSWITCH would  
>> remain to be within the module's APP funtion and continue executing  
>> the code after switch_call_extension_add_application, when let's  
>> say a 4XX or 5XX or CANCEL ( from originator) is received?
>>
>> I have tried it and found that if the bridging is successful,  
>> freeSWITCH would continue executing the code after  
>> switch_caller_extension_add_application, but if an error is  
>> received, then it would just move on to the next action.
>>
>> Does anyone know how to deal with this problem?
>>
>> Woody
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090805/4d742e71/attachment-0002.html