[Freeswitch-users] hangup_after_bridge=false not continueing after failed bridge

Mon Oct 12 08:25:53 PDT 2009

    <extension name="1999"><!--DIRECT POWER-->
      <condition field="destination_number" expression="^1997$">
        <action application="playback"
data="hh/hh-unable_to_connect_contact.wav"/>
        <action application="park"/>
      </condition>
    </extension>

my extn 1999... since it looks from the output like it's transferring, just
don't know why it's disconnecting the call instead of playing the .wav and
parking.

On Mon, Oct 12, 2009 at 10:23 PM, Matthew Fong <mattdfong at gmail.com> wrote:

> 2009-10-12 15:22:47.015952 [NOTICE] switch_core_state_machine.c:179 Hangup
> sofia/internal/sip_1 [CS_EXECUTE] [NORMAL_CLEARING]
>
> might be the line..or the entire output is below....
>
> freeswitch at matthew-laptop> originate sofia/internal/sip_1%192.168.1.10
> 1920
> 2009-10-12 15:21:44.029517 [NOTICE] switch_channel.c:613 New Channel
> sofia/internal/sip_1 [1e722934-7e94-46aa-9d62-e6ec7e7449cf]
> 2009-10-12 15:21:44.121484 [NOTICE] sofia.c:3552 Ring-Ready
> sofia/internal/sip_1!
> 2009-10-12 15:21:47.285531 [NOTICE] sofia.c:3998 Channel
> [sofia/internal/sip_1] has been answered
> 2009-10-12 15:21:47.290996 [INFO] mod_dialplan_xml.c:391 Processing
> FreeSWITCH->1920 in context default
> 2009-10-12 15:21:47.293452 [NOTICE] switch_channel.c:613 New Channel
> sofia/external/14159927717 [6b6cc440-e1d6-415a-b84b-494117e7361d]
> 2009-10-12 15:21:47.293452 [NOTICE] switch_ivr.c:1367 Transfer
> sofia/internal/sip_1 to XML[1920 at default]
> API CALL [originate(sofia/internal/sip_1%192.168.1.10 1920)] output:
> +OK 1e722934-7e94-46aa-9d62-e6ec7e7449cf
>
> freeswitch at matthew-laptop> 2009-10-12 15:21:47.369855 [NOTICE]
> sofia.c:3552 Ring-Ready sofia/external/14159927717!
> 2009-10-12 15:22:47.009474 [NOTICE] switch_ivr_originate.c:2336 Hangup
> sofia/external/14159927717 [CS_CONSUME_MEDIA] [NO_ANSWER]
> 2009-10-12 15:22:47.009474 [INFO] switch_cpp.cpp:1116 PCHangup gw:
> debug.com hc:NO_ANSWER du:0 cn:sofia/external/14159927717
> 2009-10-12 15:22:47.009474 [NOTICE] switch_core_session.c:1087 Session 47
> (sofia/external/14159927717) Ended
> 2009-10-12 15:22:47.009474 [NOTICE] switch_core_session.c:1089 Close
> Channel sofia/external/14159927717 [CS_DESTROY]
> 2009-10-12 15:22:47.009474 [INFO] mod_dptools.c:2133 Originate Failed.
>  Cause: NO_ANSWER
> 2009-10-12 15:22:47.009474 [NOTICE] switch_ivr.c:1367 Transfer
> sofia/internal/sip_1 to XML[1999 at default]
> 2009-10-12 15:22:47.009474 [INFO] mod_dialplan_xml.c:391 Processing
> FreeSWITCH->1999 in context default
> 2009-10-12 15:22:47.015952 [NOTICE] switch_core_state_machine.c:179 Hangup
> sofia/internal/sip_1 [CS_EXECUTE] [NORMAL_CLEARING]
> 2009-10-12 15:22:47.017768 [NOTICE] switch_core_session.c:1087 Session 46
> (sofia/internal/sip_1) Ended
> 2009-10-12 15:22:47.017768 [NOTICE] switch_core_session.c:1089 Close
> Channel sofia/internal/sip_1 [CS_DESTROY]
>
>
> thanks for looking at this.
>
> On Mon, Oct 12, 2009 at 10:06 PM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> which line is hanging up your A (inbound) leg?
>>
>> look for a blue line that says "Hangup xyz...." that matches it so i can
>> see.
>>
>> I think what is happening is you are getting early media so the bridge is
>> actually working then when nobody answers it dies but technically the bridge
>> worked.
>>
>> On Mon, Oct 12, 2009 at 9:41 AM, Matthew Fong <mattdfong at gmail.com>wrote:
>>
>>> I think think this might be a bug, but wanted to post here instead of
>>> Jira in-case I'm overlooking a configuration variable
>>> Dialplan
>>>
>>>     <extension name="1920"><!--init agent for manual and power dial
>>> mode-->
>>>       <condition field="destination_number" expression="^1920$">
>>>         <action application="set" data="hangup_after_bridge=false"/>
>>>         <action application="bridge" data="sofia/gateway/
>>> debug.com/14159927717"/>
>>>         <action application="transfer" data="1999"/><!-- send to unable
>>> to reach any contacts-->
>>>       </condition>
>>>     </extension>
>>>
>>> API Command
>>> originate sofia/internal/sip_1%192.168.1.10 1920
>>>
>>> When the bridge to 14159927717 fails (NO_ANSWER) both calls are
>>> terminated instead of continuing on in the dial plan to exten 1999 (which in
>>> my dialplan parks the call). hangup_after_bridge however seems to work OK if
>>> someone picks up in the bridge. Is this the correct behavior? How else can I
>>> prevent the call from hanging up if a bridge fails? Thanks.
>>>
>>> I'm using 15135M
>>>
>>> --matt
>>> http://www.hellohunter.com - Predictive Dialer
>>> http://www.hellohunter.com/voice_broadcast.php - Voice Broadcasting
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>> _______________________________________________
>> 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/20091012/f8c70d66/attachment-0002.html 