[Freeswitch-users] Hangup cause when destination is busy

[mbo]

I checked with hangup_after_bridge=true, but no change. I found out that 

<action application="set" data="continue_on_fail=false“/>

does it correctly.

Thanks

Markus


Am 18.09.2014 um 14:59 schrieb Steven Ayre <steveayre at gmail.com>:

> Try with this before the bridge:
> 
> <action application="set" data="hangup_after_bridge=true"/>
> 
> On 18 September 2014 12:23, mbo <mbodbg at gmx.net> wrote:
> Hi,
> 
> I’m originating a call from FREESWITCH1 to FREESWITCH2, which bridges the call via a gateway to a carrier.
> 
> FREESWITCH1 -> FREESWITCH2 -> CARRIER
> 
> Freeswitch2 only executes a simple dialplan like:
> 
> <extension name="bt">
>   <condition field="destination_number" expression="^(\\+\d{5,20})$">
>     <action application="bridge" data="sofia/gateway/bt/${destination_number}"/>
>   </condition>
> </extension>
> 
> 
> When the destination is BUSY, I can see in the logs
> 
> ...
> [NOTICE] switch_core_state_machine.c:313 sofia/internal/XXXXXXXXXX has executed the last dialplan instruction, hanging up.
> [NOTICE] switch_core_state_machine.c:315 Hangup sofia/internal/XXXXXXXXXX [CS_EXECUTE] [NORMAL_CLEARING]
> …
> 
> FREESWITCH2 hangs up with cause NORMAL_CLEARING after the bridge, and then sends
> 
> ...
> 
>  SIP/2.0 486 Busy Here
>    Via: SIP/2.0/UDP 192.168.154.100:5080;rport=5080;branch=z9hG4bK18gUcH38BXQ8H
>    Max-Forwards: 65
>    From: „XXXXXXXXXXXXX>;tag=S4SS3j0HyUv2Q
>    To: <XXXXXXXXXXXXX>;tag=B7XU8ZtQUDvrF
>    Call-ID: b61b6f21-b9ab-1232-5abc-00163e6b3124
>    CSeq: 65177338 INVITE
>    User-Agent: FreeSWITCH-mod_sofia/1.4.6+git~20140603T193516Z~9479729340~64bit
>    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>    Supported: timer, path, replaces
>    Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
>    Reason: Q.850;cause=16;text="NORMAL_CLEARING"
>    Content-Length: 0
>    X-FS-Display-Name: Outbound Call
>    X-FS-Display-Number: XXXXXXXXXXXX
>    Remote-Party-ID: "Outbound Call“ <XXXXXXXXXXXX>;party=calling;privacy=off;screen=no
> …
> 
> to FREESWITCH1. In the CDR on FREESWITCH1, the hangup cause for the call is NORMAL_CLEARING and not USER_BUSY.
> Does this really works as designed or shouldn’t it hangup with hangup cause „USER_BUSY" and then set "Reason: Q.850;cause=17;text=„USER_BUSY“" in the SIP/2.0 486 Busy Here message, which is sent to FREESWITCH1?
> 
> 
> 
> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> 
> 
> 
> 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
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services: 
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> 
> 
> 
> 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/20140918/24f333f2/attachment.html