<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 <mattdf...@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....
>
> freeswi...@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[1...@default]
> API CALL [originate(sofia/internal/sip_1%192.168.1.10 1920)] output:
> +OK 1e722934-7e94-46aa-9d62-e6ec7e7449cf
>
> freeswi...@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[1...@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.miness...@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 <mattdf...@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@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_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
>> iax:gu...@conference.freeswitch.org/888
>> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Reply via email to