183 automatically marks origination as success?
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
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
If I'm bridging serially - endpoint|endpoind2|endpoint3, what effect does ignore_early_media=true have? I read the wiki pages and I'm not altogether sure. Does it just not not mark it as a success or will I not actually hear the early media? It sounds like it will completely ignore it, unless I use ignore_early_media=ring_ready in which case it will both not mark it a success and also send back a 180 to the other leg. I think I just need to not mark it a success, otherwise, I don't need to kill the early media. Thanks, -Avi Marcus On Thu, Aug 20, 2015 at 3:30 PM, Í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
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
FreeSWITCH considers a 183 with media as successful origination of call, as in "you want to ear the early media". If you don't, you set "ignore-early-media" to true. sent from my mobile, Giovanni Maruzzelli cell: +39 347 266 56 18 On Aug 20, 2015 5:44 PM, "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
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
-- 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@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
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
-- 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@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ 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
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
-- 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@conference.freeswitch.org ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
_________________________________________________________________________ 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 ♬ ☞ 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@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
A bit more... if your bridging to multiple dests like this, you don't want to pass along the early media, as this could be very confusing to the users in the case of conflicting inband media. Without ignoring early media, you could get an inband error, followed by successfully connecting to an additional dest. This is why you would want to ignore early media and use ringback in these scenarios as Tony described.
On Aug 20, 2015, at 12:46 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
-- Ítalo Rossi _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ <http://freeswitch.org/> ☞ http://cluecon.com/ <http://cluecon.com/> ☞ http://twitter.com/FreeSWITCH <http://twitter.com/FreeSWITCH> ☞ irc.freenode.net <http://irc.freenode.net/> #freeswitch ☞ http://freeswitch.org/g+ <http://freeswitch.org/g+>
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ☎ +19193869900 <tel:%2B19193869900>
https://www.youtube.com/watch?v=9XXgW34t40s <https://www.youtube.com/watch?v=9XXgW34t40s> https://www.youtube.com/watch?v=NLaDpGQuZDA <https://www.youtube.com/watch?v=NLaDpGQuZDA>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬
☞ http://freeswitch.org/ <http://freeswitch.org/> ☞ http://cluecon.com/ <http://cluecon.com/> ☞ http://twitter.com/FreeSWITCH <http://twitter.com/FreeSWITCH> ☞ irc.freenode.net <http://irc.freenode.net/> #freeswitch ☞ http://freeswitch.org/g+ <http://freeswitch.org/g+>
ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> ☎ +19193869900
https://www.youtube.com/watch?v=9XXgW34t40s <https://www.youtube.com/watch?v=9XXgW34t40s> https://www.youtube.com/watch?v=NLaDpGQuZDA <https://www.youtube.com/watch?v=NLaDpGQuZDA> _________________________________________________________________________ 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
participants (6)
-
Anthony Minessale
-
Avi Marcus
-
Giovanni Maruzzelli
-
Lawrence Conroy
-
Michael Jerris
-
Ítalo Rossi