Is there a way to deal with "false ring-back than 503" carriers?
Hello, A downstream carrier would accept INVITE, send 183 w/SDP, and almost instantaneously respond "503". This kills the call not letting re-route to the next carrier. Without calling any specific names, this seems to become more common. Unfortunately, often the offending carrier is a few steps down the call path and I can't reach them with a cluebat. Is there a way to make FS not fail the call and try the next route if using LCR as per below? Note that we are in bypass_media mode: <action application="set" data="bypass_media=true"/> <action application="bridge" data="lcr/lcr_profile/${destination_number}"/> Or to keep it simple, forget LCR for a moment, can we make it go to gateway_2 in the following example if gw1 returns "183" followed by "503"? <action application="set" data="bypass_media=true"/> <action application="bridge" data="sofia/gateway/gw_1/${destination_number}|sofia/gateway/gw_2/${destination_number}"/> Many thanks, -Victor
You can't continue in bypass media mode because (wrong) media IP/port already sent to your downstream. Even if the second gateway completes the call OK, you will get one way audio. So either proxy the media or fail the call. On Wednesday 03 February 2016 15:07:29 Victor Chukalovskiy wrote:
Hello,
A downstream carrier would accept INVITE, send 183 w/SDP, and almost instantaneously respond "503". This kills the call not letting re-route to the next carrier.
Without calling any specific names, this seems to become more common. Unfortunately, often the offending carrier is a few steps down the call path and I can't reach them with a cluebat.
Is there a way to make FS not fail the call and try the next route if using LCR as per below? Note that we are in bypass_media mode:
<action application="set" data="bypass_media=true"/> <action application="bridge" data="lcr/lcr_profile/${destination_number}"/>
Or to keep it simple, forget LCR for a moment, can we make it go to gateway_2 in the following example if gw1 returns "183" followed by "503"?
<action application="set" data="bypass_media=true"/> <action application="bridge" data="sofia/gateway/gw_1/${destination_number}|sofia/gateway/gw_2/${destinat ion_number}"/>
Many thanks, -Victor
_________________________________________________________________________ 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
Thank you! Hypothesising there is a way to ontinue to #2 while in bypass_media, as soon as I get 183 SDP from the 2nd carrier, wouldn't it override bogus 183 SDP from the first carrier? It's not an ideal scenario to have two distinct 183's on the same call, but should be doable, no? In proxy_media, is there an additional param or var I'd need in order to continue to #2? Would that be ignore_early_media, or something else? On 16-02-03 04:48 PM, Sergey Okhapkin wrote:
You can't continue in bypass media mode because (wrong) media IP/port already sent to your downstream. Even if the second gateway completes the call OK, you will get one way audio.
So either proxy the media or fail the call.
On Wednesday 03 February 2016 15:07:29 Victor Chukalovskiy wrote:
Hello,
A downstream carrier would accept INVITE, send 183 w/SDP, and almost instantaneously respond "503". This kills the call not letting re-route to the next carrier.
Without calling any specific names, this seems to become more common. Unfortunately, often the offending carrier is a few steps down the call path and I can't reach them with a cluebat.
Is there a way to make FS not fail the call and try the next route if using LCR as per below? Note that we are in bypass_media mode:
<action application="set" data="bypass_media=true"/> <action application="bridge" data="lcr/lcr_profile/${destination_number}"/>
Or to keep it simple, forget LCR for a moment, can we make it go to gateway_2 in the following example if gw1 returns "183" followed by "503"?
<action application="set" data="bypass_media=true"/> <action application="bridge" data="sofia/gateway/gw_1/${destination_number}|sofia/gateway/gw_2/${destinat ion_number}"/>
Many thanks, -Victor
_________________________________________________________________________ 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
Unfortunately 183 from the second gateway will not override the first one. It's how SIP offer/answer works. Once media IP provided to calling party, it can't be changed. Set "continue_on_fail=true" and do not set bypass_media. On Wednesday 03 February 2016 16:58:09 Victor Chukalovskiy wrote:
Thank you! Hypothesising there is a way to ontinue to #2 while in bypass_media, as soon as I get 183 SDP from the 2nd carrier, wouldn't it override bogus 183 SDP from the first carrier? It's not an ideal scenario to have two distinct 183's on the same call, but should be doable, no?
In proxy_media, is there an additional param or var I'd need in order to continue to #2? Would that be ignore_early_media, or something else?
On 16-02-03 04:48 PM, Sergey Okhapkin wrote:
You can't continue in bypass media mode because (wrong) media IP/port already sent to your downstream. Even if the second gateway completes the call OK, you will get one way audio.
So either proxy the media or fail the call.
On Wednesday 03 February 2016 15:07:29 Victor Chukalovskiy wrote:
Hello,
A downstream carrier would accept INVITE, send 183 w/SDP, and almost instantaneously respond "503". This kills the call not letting re-route to the next carrier.
Without calling any specific names, this seems to become more common. Unfortunately, often the offending carrier is a few steps down the call path and I can't reach them with a cluebat.
Is there a way to make FS not fail the call and try the next route if using LCR as per below? Note that we are in bypass_media mode:
<action application="set" data="bypass_media=true"/> <action application="bridge" data="lcr/lcr_profile/${destination_number}"/>
Or to keep it simple, forget LCR for a moment, can we make it go to gateway_2 in the following example if gw1 returns "183" followed by "503"?
<action application="set" data="bypass_media=true"/> <action application="bridge" data="sofia/gateway/gw_1/${destination_number}|sofia/gateway/gw_2/${desti nat ion_number}"/>
Many thanks, -Victor
_________________________________________________________________________ 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
participants (2)
-
Sergey Okhapkin
-
Victor Chukalovskiy