When you are doing a complicated multi-dest originate the best practice is to set the ringback variable on the A leg to a local ring tone.
Then as soon as any of the legs being dialed hit a 180 or 183 the A leg will hear generated ringback.

for instance

<action application="set" data="ringback=%(2000,4000,440,480)"/>

Will generate US ring 



On Thu, Aug 20, 2015 at 11:42 AM, Avi Marcus <avi@avimarcus.net> wrote:
Thanks Anthony.

What happens to the user on the A leg trying to call with ignore_early_media=true - does he hear anything? Or do I need to do ignore_early_media=ring_ready?
This wasn't clear from the wiki / confluence.


Thanks,
-Avi Marcus

On Thu, Aug 20, 2015 at 7:09 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
The discussion was about the success of the FreeSWITCH originate function which by default returns as soon as media is possible.  That should not be confused with the success of the call leg itself.
The originate function has many complex params to control behavior.  As many have stated ignore_early_media=true will make originate only return on an answered call.

On Thu, Aug 20, 2015 at 10:42 AM, Lawrence Conroy <lconroy@insensate.co.uk> wrote:
Hi there,
 um ... are we talking about SIP here?
2xx are invite successful final responses; 3xx are transfer final responses whilst 4xx, 5xx are final errors. 1xx are temporary responses.
Thus a 1xx followed by a 4xx (or 5xx) is not a success.
Or have I missed something in RFC2543 or 3761?

all the best,
  Lawrence


On 20 Aug 2015, at 13:30, Ítalo Rossi <italorossib@gmail.com> wrote:

> 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
> _________________________________________________________________________
> 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


_________________________________________________________________________
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



--

_________________________________________________________________________
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


_________________________________________________________________________
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



--
Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬

ClueCon Weekly Development Call 
☎ sip:888@conference.freeswitch.org  ☎ +19193869900