I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ? I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all. Regards, Ross
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
I want to do something like this, but using another header instead of Reason header. Is it possible? Santiago Soares Fone: (41) 8488-0537 On Wed, Nov 10, 2010 at 3:03 PM, Eduardo Nunes Pereira < eduardonunesp@gmail.com> wrote:
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true
On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
_______________________________________________ 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
Maybe if you use application export On Wed, Nov 10, 2010 at 4:34 PM, Santiago Soares <santiagosoares@gmail.com> wrote:
I want to do something like this, but using another header instead of Reason header. Is it possible?
Santiago Soares Fone: (41) 8488-0537
On Wed, Nov 10, 2010 at 3:03 PM, Eduardo Nunes Pereira <eduardonunesp@gmail.com> wrote:
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true
On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
Try: <action application="set" data="hangup_on_bridge=false" /> <action application="bridge" data="..." /> <action application="set" data="sip_bye_h_X-Remote-Reason=${bridge_hangup_cause}" /> <action application="hangup" /> It won't have any effect if the A-leg hangs up though (the call will end during the bridge so won't reach the sip_h set). If the B-leg hangs up it'll take the B-leg cause and set it in a X-Remote-Reason header of the BYE to the A-leg. Note the bye needs sip_bye_h_ not the usual sip_h_ prefix. -Steve On 10 November 2010 18:34, Santiago Soares <santiagosoares@gmail.com> wrote:
I want to do something like this, but using another header instead of Reason header. Is it possible?
Santiago Soares Fone: (41) 8488-0537
On Wed, Nov 10, 2010 at 3:03 PM, Eduardo Nunes Pereira <eduardonunesp@gmail.com> wrote:
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true
On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
_______________________________________________ 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
On 10 Nov 2010, at 20:09, Steven Ayre wrote:
<action application="set" data="hangup_on_bridge=false" /> <action application="bridge" data="..." /> <action application="set" data="sip_bye_h_X-Remote-Reason=${bridge_hangup_cause}" /> <action application="hangup" />
It won't have any effect if the A-leg hangs up though (the call will end during the bridge so won't reach the sip_h set).
If the B-leg hangs up it'll take the B-leg cause and set it in a X-Remote-Reason header of the BYE to the A-leg. Note the bye needs sip_bye_h_ not the usual sip_h_ prefix.
Hi Steven, Thanks for the advice - seems it's not getting far enough to set the header, looks like the originate itself fails;
2010-11-12 21:17:03.143772 [INFO] mod_dptools.c:2355 Originate Failed. Cause: NO_USER_RESPONSE
But in the SIP i'm getting this back from the ITSP; SIP/2.0 480 Temporarily Unavailable. Via: SIP/2.0/UDP 10.0.0.148;rport=5060;branch=z9hG4bKgr8NmB1964Hge;received=10.0.0.148. From: "A" <sip:A@10.0.0.148>;tag=gQZc0K4X2gF2D. To: <sip:B@10.0.0.131>;tag=8S8P051IJW30000E1D00001l1RKICZL1UU3V64. Call-ID: 16dfe84a-6945-122e-ad83-0011433127d9. CSeq: 4462259 INVITE. Reason: Q.850;cause=31. Content-Length: 0. And FreeSWITCH is then sending this back to my calling device; SIP/2.0 480 Temporarily Unavailable. Via: SIP/2.0/UDP 10.0.0.140:5060;branch=z9hG4bK26c545d4;rport=5060. From: "A" <sip:A@10.0.0.140>;tag=as246a165b. To: <sip:B@10.0.0.148>;tag=Fe6KyrKt57rFj. Call-ID: 39ae1b6f29920d836099bf6a247c8c63@10.0.0.140. CSeq: 102 INVITE. User-Agent: FreeSWITCH. Accept: application/sdp. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY. Supported: timer, precondition, path, replaces. Allow-Events: talk, refer. Reason: Q.850;cause=16;text="NORMAL_CLEARING". Content-Length: 0. Remote-Party-ID: "B" <sip:B@10.0.0.148>;party=calling;privacy=off;screen=no. Note the disparity between the two causes in the Reason: header... Ross
Except he's saying that he's *not* getting the remote reason. Ross, can you post a debug-level log for the call? -Steve On 10 November 2010 17:03, Eduardo Nunes Pereira <eduardonunesp@gmail.com> wrote:
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true
On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
_______________________________________________ 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
-- Eduardo Nunes Pereira cel.: (48) 9989-2997 email: eduardonunesp@gmail.com
_______________________________________________ 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
Happy New Year All, Sorry to drag this one up again.. I thought I had resolved this but I haven't.. The dialplan is now as follows;
<action application="set" data="continue_on_fail=true" /> <action application="set" data="hangup_after_bridge=false" /> <action application="set" data="sip_ignore_remote_cause=true" /> <action application="bridge" data="{bypass_media=true}sofia/external/NUMBER@10.0.44.1" /> <action application="log" data="WARNING HC : ${hangup_cause} / BHC: ${bridge_hangup_cause} / OD: ${originate_disposition}" /> <action application="hangup" data="${bridge_hangup_cause}" />
(have also tried <action application="hangup" data="${originate_disposition}" /> as well as not setting the sip_ignore_remote_cause variable) Of interest, perhaps, is that sometimes early media is returned with the 183 Session Progress (usually a recorded message from the remote party explaining the fault) before the call is dropped by the TDM switch with a 480 and Reason header containing an appropriate cause code. I simply want FreeSWITCH to pass the Reason header from the bridge attempt back to the A party unchanged. I had limited success using ${originate_disposition} in the hangup application however this does not work where there's early media (and in any event doesn't return the same q.850 code but it does return something indicative of an error (usually) "NO_USER_RESPONSE" but still with a code 16. SIP Trace (altered to remove some host-identifying information) is available at; http://pastebin.freeswitch.org/14949 Regards, Ross On 10 Nov 2010, at 17:03, Eduardo Nunes Pereira wrote:
If you use hangup after a bridge FreeSWITCH overrides the cause with the cause recieved from the bridge application. You can avoid this using sip_ignore_remote_cause=true
On Wed, Nov 10, 2010 at 12:25 PM, Ross McKillop <ross@ossiantelecom.co.uk> wrote:
I have a FreeSWITCH box acting as a gateway between other servers and a TDM switch, primarily for accounting purposes - The TDM switch accurately sets a Reason header as follows;
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=31.
This is then passed by FreeSWITCH back to the A party as
SIP/2.0 480 Temporarily Unavailable. Reason: Q.850;cause=16;text="NORMAL_CLEARING".
Is there any way to get FreeSWITCH to use the Reason header from the failed B leg when replying to the A party ?
I tried setting continue_on_fail=true and hangup_after_bridge=false and then adding a line after the bridge in the dialplan to hangup with the bridge hangup cause e.g.;
<action application="hangup" data="${bridge_hangup_cause}" />
But that hasn't affected the behaviour at all.
Regards, Ross
On 7 Jan 2011, at 15:12, Brian West wrote:
don't call hangup at all... Just let it pass it back.
Do you need hangup_after_bridge=true for this ? Previously (with hangup_after_bridge true + no hangup application call) it still returned 16 "NORMAL_CLEARING" even when the B party ended with cause 31.
On Jan 7, 2011, at 5:04 AM, Ross McKillop wrote:
(have also tried <action application="hangup" data="${originate_disposition}" /> as well as not setting the sip_ignore_remote_cause variable)
I've been away for a while and recently had a chance to come back to look at this issue (which a colleague has also attempted to resolve without success) On 7 Jan 2011, at 15:12, Brian West wrote:
don't call hangup at all... Just let it pass it back.
I've tried this also with and without hangup_after_bridge=true Still returned 16 "NORMAL_CLEARING" even when the B party ended with cause 31. Tried this in both 1.0.6 and git-head from December 8th. Could this be related to the (older) thread "FreeSWITCH overrides/dose no accept hangup cause"?
On Jan 7, 2011, at 5:04 AM, Ross McKillop wrote:
(have also tried <action application="hangup" data="${originate_disposition}" /> as well as not setting the sip_ignore_remote_cause variable)
participants (5)
-
Brian West
-
Eduardo Nunes Pereira
-
Ross McKillop
-
Santiago Soares
-
Steven Ayre