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