Correct, expected. A call is considered successful when you receive media, 183 or 200. If you need to change this behavior you'll need to set ignore_early_media=true before bridging. If you can't ignore_early_media, you need to set hangup_after_bridge=false and do more verifications on what happened after your last bridge. On Thu, Aug 20, 2015 at 8:37 AM, Avi Marcus <avi@avimarcus.net> wrote:
I have several carriers, and I use: <action application="set" data="continue_on_fail=true"/> ... so I was a little surprised to see that a call that ended with NORMAL_TEMPORARY_FAILURE didn't route advance. I dug into the PCAPs of this and comparable, and the only difference I noticed was that the ones that worked were invite -> 100 and then 503 NORMAL_TEMPORARY_FAILURE and the one that didn't work was invite -> 100, 183, and then 503.
I have a lua script that told me:
session:getVariable("originate_disposition") = SUCCESS session:getVariable("bridge_hangup_cause") = NORMAL_TEMPORARY_FAILURE
so... I'm guessing that a 183 marks the originate as a success which is why continue_on_fail didn't work, since it wasn't a fail.
Is this expected? Is the carrier "doing something wrong" here?
They did helpfully send: "SIP/2.0 503 Service Unavailable - Route Advance" More importantly: how can I fix it?
Thanks,
-Avi Marcus BestFone
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi