Discussion:
[Freeswitch-users] RECOVERY_ON_TIMER_EXPIRE + Changing Hangup Cause
Massimo Varriale
2014-09-03 11:01:35 UTC
Permalink
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in general since it's 15 years experience in telco companies. However I'm still facing a problem I couldn't find any solution yet and i hope someone could help in finding a solution


As my present company can't afford an expensive soft switch I'm using Freeswitch 1.4 with a simple dialplan.xml and some scripts to load CDRs into mysql to send incoming calls to my remote peers. At present the live traffic is only 1 incoming IP and 1 outgoing peer, quite easy.

On some calls I'm getting "408 Request Timeout" and FS is giving me a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of the switches are not able to make automatic rerouting based on this cause and so, I will like to use instead the ISDN Cause 18 (I suppose "480 Temporarily unavailable").
Is this possible?


I've used this snippet of code that use another relcause but with same concept (taken as is and pasted into the dialplan) but doesn't work as the 408 is given after 183.

<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge" data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>




How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be possible also to change the source code and recompile FS accordly?


Thank yo so much and sorry for this long post
I hope someone could help
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140903/60c72108/attachment.html
Brian West
2014-09-03 12:34:45 UTC
Permalink
RECOVERY_ON_TIMER_EXPIRE usually means you have a NAT issue, can you
clarify your signaling paths?
Post by Massimo Varriale
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in general
since it's 15 years experience in telco companies. However I'm still facing
a problem I couldn't find any solution yet and i hope someone could help in
finding a solution
As my present company can't afford an expensive soft switch I'm using *Freeswitch
1.4* with a simple *dialplan.xml* and some scripts to load *CDRs into
mysql* to send incoming calls to my remote peers. At present the live
traffic is only *1 incoming IP* and *1 outgoing peer*, quite easy.
On some calls I'm getting "408 Request Timeout" and FS is giving me
a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of
the switches are not able to make automatic rerouting based on this cause
and so, I will like to use instead the ISDN Cause 18 (I suppose "480
Temporarily unavailable").
Is this possible?
I've used this snippet of code that use another relcause but with same
concept (taken as is and pasted into the dialplan) but doesn't work as the
408 is given after 183.
<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge"
data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="
sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>
How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be
possible also to change the source code and recompile FS accordly?
Thank yo so much and sorry for this long post
I hope someone could help
Max
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
*Brian West*
brian at freeswitch.org


*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com

*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140903/9ba8c102/attachment.html
Massimo Varriale
2014-09-03 12:44:59 UTC
Permalink
Hi Brian,
thanks for answering me!
Actually I'm sure (or better quite sure) it's not something related to NAT
as all the end points are using plain public IP addresses.
They are some dedicated servers under OVH provider and they just use
IPTABLES and FS ACL for allowing communications each other (this means no
hard-FW)

The scenario could be easily explained like this:
Inbound (Public) + My FS 1.4 (Public) + Outbound (TELES Switch with Public
IP Voip Card + PSTN E1 Interconnections)

And also the FS is started with option -nonat, does this affect ?

Thank you so much
Max
Post by Brian West
RECOVERY_ON_TIMER_EXPIRE usually means you have a NAT issue, can you
clarify your signaling paths?
Post by Massimo Varriale
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in general
since it's 15 years experience in telco companies. However I'm still facing
a problem I couldn't find any solution yet and i hope someone could help in
finding a solution
As my present company can't afford an expensive soft switch I'm using *Freeswitch
1.4* with a simple *dialplan.xml* and some scripts to load *CDRs into
mysql* to send incoming calls to my remote peers. At present the live
traffic is only *1 incoming IP* and *1 outgoing peer*, quite easy.
On some calls I'm getting "408 Request Timeout" and FS is giving me
a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of
the switches are not able to make automatic rerouting based on this cause
and so, I will like to use instead the ISDN Cause 18 (I suppose "480
Temporarily unavailable").
Is this possible?
I've used this snippet of code that use another relcause but with same
concept (taken as is and pasted into the dialplan) but doesn't work as the
408 is given after 183.
<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge"
data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="
sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>
How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be
possible also to change the source code and recompile FS accordly?
Thank yo so much and sorry for this long post
I hope someone could help
Max
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
*Brian West*
brian at freeswitch.org
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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/20140903/3ade1eba/attachment.html
Guillermo Ruiz Camauer
2014-09-03 17:42:08 UTC
Permalink
I have gotten RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102) from my provider by
just letting the phone ring for too long (and no answering service). Could
that be the cause?

Guillermo
Post by Massimo Varriale
Hi Brian,
thanks for answering me!
Actually I'm sure (or better quite sure) it's not something related to NAT
as all the end points are using plain public IP addresses.
They are some dedicated servers under OVH provider and they just use
IPTABLES and FS ACL for allowing communications each other (this means no
hard-FW)
Inbound (Public) + My FS 1.4 (Public) + Outbound (TELES Switch with Public
IP Voip Card + PSTN E1 Interconnections)
And also the FS is started with option -nonat, does this affect ?
Thank you so much
Max
RECOVERY_ON_TIMER_EXPIRE usually means you have a NAT issue, can you
Post by Brian West
clarify your signaling paths?
Post by Massimo Varriale
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in
general since it's 15 years experience in telco companies. However I'm
still facing a problem I couldn't find any solution yet and i hope someone
could help in finding a solution
As my present company can't afford an expensive soft switch I'm using *Freeswitch
1.4* with a simple *dialplan.xml* and some scripts to load *CDRs into
mysql* to send incoming calls to my remote peers. At present the live
traffic is only *1 incoming IP* and *1 outgoing peer*, quite easy.
On some calls I'm getting "408 Request Timeout" and FS is giving me
a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of
the switches are not able to make automatic rerouting based on this cause
and so, I will like to use instead the ISDN Cause 18 (I suppose "480
Temporarily unavailable").
Is this possible?
I've used this snippet of code that use another relcause but with same
concept (taken as is and pasted into the dialplan) but doesn't work as the
408 is given after 183.
<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge"
data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="
sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>
How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be
possible also to change the source code and recompile FS accordly?
Thank yo so much and sorry for this long post
I hope someone could help
Max
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
*Brian West*
brian at freeswitch.org
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
Guillermo Ruiz Camauer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140903/3ef6542a/attachment.html
mvar78
2014-09-03 19:15:15 UTC
Permalink
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140903/b10d23e1/attachment-0001.html
Anthony Minessale
2014-09-03 20:07:34 UTC
Permalink
Did you look at the whole sip trace? This sounds like a typical missing
ack scenario.
Sometimes the Contact in one of the packets or other routing issues cause
the other end to send the ack to the wrong place.
When the sip stack doesn't get the ack, it aborts the call even though
media was up.
Hi Guillermo!
On normal behaviours I can accept the cause 19 that is "no user responding
(user alerted)" because actually your phone ringed for a prolonged time and
you didn't answer.
Instead, the timeout is not so "nice" to give back as it means that the
outbound carrier some way didn't managed the call..
And then my inbound IP can't make accurate rerouting caused by the
timeout.
I think that an alternative could be recompile fs making appropriate
chAnges into the source, but I need some hints where...
I have gotten RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102) from my provider
by just letting the phone ring for too long (and no answering service).
Could that be the cause?
Guillermo
Post by Massimo Varriale
Hi Brian,
thanks for answering me!
Actually I'm sure (or better quite sure) it's not something related to
NAT as all the end points are using plain public IP addresses.
They are some dedicated servers under OVH provider and they just use
IPTABLES and FS ACL for allowing communications each other (this means no
hard-FW)
Inbound (Public) + My FS 1.4 (Public) + Outbound (TELES Switch with
Public IP Voip Card + PSTN E1 Interconnections)
And also the FS is started with option -nonat, does this affect ?
Thank you so much
Max
RECOVERY_ON_TIMER_EXPIRE usually means you have a NAT issue, can you
Post by Brian West
clarify your signaling paths?
On Wed, Sep 3, 2014 at 6:01 AM, Massimo Varriale <mvar78 at gmail.com>
Post by Massimo Varriale
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in
general since it's 15 years experience in telco companies. However I'm
still facing a problem I couldn't find any solution yet and i hope someone
could help in finding a solution
As my present company can't afford an expensive soft switch I'm using *Freeswitch
1.4* with a simple *dialplan.xml* and some scripts to load *CDRs into
mysql* to send incoming calls to my remote peers. At present the live
traffic is only *1 incoming IP* and *1 outgoing peer*, quite easy.
On some calls I'm getting "408 Request Timeout" and FS is giving me
a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of
the switches are not able to make automatic rerouting based on this cause
and so, I will like to use instead the ISDN Cause 18 (I suppose "480
Temporarily unavailable").
Is this possible?
I've used this snippet of code that use another relcause but with same
concept (taken as is and pasted into the dialplan) but doesn't work as the
408 is given after 183.
<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge"
data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="
sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>
How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be
possible also to change the source code and recompile FS accordly?
Thank yo so much and sorry for this long post
I hope someone could help
Max
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
*Brian West*
brian at freeswitch.org
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
Guillermo Ruiz Camauer
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
Anthony Minessale II ? @anthmfs ? @FreeSWITCH ?

? http://freeswitch.org/ ? http://cluecon.com/ ?
http://twitter.com/FreeSWITCH
? irc.freenode.net #freeswitch ? *http://freeswitch.org/g+
<http://freeswitch.org/g+>*

ClueCon Weekly Development Call
? sip:888 at conference.freeswitch.org ? +19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140903/343bc33e/attachment-0001.html
Massimo Varriale
2014-09-05 11:34:22 UTC
Permalink
Hi Guys!
Today I found some email has been put as SPAM by Gmail and I wonder if someone else answered to my question and I lost the email...

Thanks Antony for your answer, I will send the trace to check if I got the ACK or not.
And then it doesn't happen all days to get an answer from the FATHER of FS, I never imagined something like that! Thank you so much!

Max
Did you look at the whole sip trace? This sounds like a typical missing ack scenario.
Sometimes the Contact in one of the packets or other routing issues cause the other end to send the ack to the wrong place.
When the sip stack doesn't get the ack, it aborts the call even though media was up.
Hi Guillermo!
On normal behaviours I can accept the cause 19 that is "no user responding (user alerted)" because actually your phone ringed for a prolonged time and you didn't answer.
Instead, the timeout is not so "nice" to give back as it means that the outbound carrier some way didn't managed the call..
And then my inbound IP can't make accurate rerouting caused by the timeout.
I think that an alternative could be recompile fs making appropriate chAnges into the source, but I need some hints where...
I have gotten RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102) from my provider by just letting the phone ring for too long (and no answering service). Could that be the cause?
Guillermo
Hi Brian,
thanks for answering me!
Actually I'm sure (or better quite sure) it's not something related to NAT as all the end points are using plain public IP addresses.
They are some dedicated servers under OVH provider and they just use IPTABLES and FS ACL for allowing communications each other (this means no hard-FW)
Inbound (Public) + My FS 1.4 (Public) + Outbound (TELES Switch with Public IP Voip Card + PSTN E1 Interconnections)
And also the FS is started with option -nonat, does this affect ?
Thank you so much
Max
RECOVERY_ON_TIMER_EXPIRE usually means you have a NAT issue, can you clarify your signaling paths?
Hi All!
This is my first question...and what question...
I'm a skilled developer and I'm almost familiar with telephony in general since it's 15 years experience in telco companies. However I'm still facing a problem I couldn't find any solution yet and i hope someone could help in finding a solution
As my present company can't afford an expensive soft switch I'm using Freeswitch 1.4 with a simple dialplan.xml and some scripts to load CDRs into mysql to send incoming calls to my remote peers. At present the live traffic is only 1 incoming IP and 1 outgoing peer, quite easy.
On some calls I'm getting "408 Request Timeout" and FS is giving me a RECOVERY_ON_TIMER_EXPIRE cause (IDSN 102). The problem is that as most of the switches are not able to make automatic rerouting based on this cause and so, I will like to use instead the ISDN Cause 18 (I suppose "480 Temporarily unavailable").
Is this possible?
I've used this snippet of code that use another relcause but with same concept (taken as is and pasted into the dialplan) but doesn't work as the 408 is given after 183.
<extension name="AllDestinations_Inbound">
<condition field="destination_number" expression="^">
<condition field="network_addr" expression="^154\.48\.198\.190$"/>
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=19"/>
<action application="bridge" data="sofia/gateway/remote_outbound_peer/${destination_number}"/>
<action application="transfer" data="408to503"/>
</condition>
</extension>
<!--ISDN CAU 34 -->
<extension name="408to503">
<condition field="${proto_specific_hangup_cause}" expression="<a href="sip:408">sip:408">
<action application="set" data="sip_ignore_remote_cause=true"/>
<action application="respond" data="503"/>
<action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/>
</condition>
</extension>
How to correctly remap causes?
If there is no way to change normal behaviour, do you think could be possible also to change the source code and recompile FS accordly?
Thank yo so much and sorry for this long post
I hope someone could help
Max
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
Brian West
brian at freeswitch.org
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com
T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
Guillermo Ruiz Camauer
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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
--
? http://freeswitch.org/ ? http://cluecon.com/ ? http://twitter.com/FreeSWITCH
? irc.freenode.net #freeswitch ? http://freeswitch.org/g+
ClueCon Weekly Development Call
? sip:888 at conference.freeswitch.org ? +19193869900
_________________________________________________________________________
consulting at freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.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/20140905/1e71f896/attachment-0001.html
Loading...