Help rewriting hangup causes
Dear All, I posted a thread re the subject but didn't get any joy, so perhaps second time lucky. I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc). I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten. I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml. By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour. Any help with this would be highly appreciated. Regards, Ahmed.
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
Hi Michael, This is exactly what I'm doing, but it's just not happening. Thanks, Ahmed. 2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
Can you show us the dialplan extension you're trying? Thanks, -Steve 2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
_______________________________________________ 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
Here you go: <condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$" break="on-true"> <action inline="true" application="set" data="bypass_media=false"/> <action inline="true" application="set" data="prpoxy_media=false"/> <action inline="true" application="set" data="disable_q850_reason=true"/> <action inline="true" application="set" data="hangup_after_bridge=false"/> <action inline="true" application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action inline="true" application="set" data="bridge_hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action inline="true" application="set" data="hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action application="bridge" data="error/normal_circuit_congestion"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition> As you can see, I am trying to rewrite the hangup codes in a multitude of ways and places, but still exhibit the same behaviour. Any help appreciated. Regards, Ahmed. 2010/1/12 Steven Ayre <steveayre@gmail.com>
Can you show us the dialplan extension you're trying?
Thanks, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com>
wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION
and
no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
;) 2010/1/12 Russell Mosemann <Russell.Mosemann@cune.org>
<action inline="true" application="set" data="prpoxy_media=false"/>
prpoxy? ;-)
-- Russell Mosemann
_______________________________________________ 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
-- Ahmed Naji
- prpoxy_media should be proxy_media - bypass_media and proxy_media shouldn't need setting to false - that's their default (unless you're set one of them to true on the sip profile?) - why do you need to disable q850 reason? I do something very similar - try this... <condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition> By the way, you'll be unable to rewrite the hangup cause for a bridge that gets a 180 or 183 packet from the gateway before getting a 4xx, 5xx or 6xx packet (because those bridges don't 'fail') - I've seen this on a SIP provider before who gives 183 Session Progress before a 404 Not Found if the PSTN number dialled doesn't exist. Regards, -Steve 2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Here you go:
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$" break="on-true"> <action inline="true" application="set" data="bypass_media=false"/> <action inline="true" application="set" data="prpoxy_media=false"/> <action inline="true" application="set" data="disable_q850_reason=true"/> <action inline="true" application="set" data="hangup_after_bridge=false"/> <action inline="true" application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action inline="true" application="set" data="bridge_hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action inline="true" application="set" data="hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action application="bridge" data="error/normal_circuit_congestion"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
As you can see, I am trying to rewrite the hangup codes in a multitude of ways and places, but still exhibit the same behaviour.
Any help appreciated.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
Can you show us the dialplan extension you're trying?
Thanks, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean NORMAL_CONGESTION and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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
Steve/All, Thanks for all your feedback, this thread can be closed. Here is some feedback: Re: Steve's queries: - "pproxy" was a typo on my part, but it should not affect anything. I set them both to false in vars.xml, and don't over-ride them anywhere. - true re: default values for proxy_media & bypass_media being false. I am explicitly setting them here out of 1) paranoia and 2) I like to make sure I know my variable values and not leave them to defaults - relics of being a developer - I was disabling the q850 code as part of my attempts to crack this nut. Re: the solution, I've managed to rewrite some of the codes with a call to the hangup app, which is what Steve is also using, and his findings re: bridges getting 183 and 180 before 4xx. I wonder if it's possible to rewrite causes from such bridges by executing a JS or similar app attached to the bridge. I'll report on this as and when. Regards, Ahmed. 2010/1/12 Steven Ayre <steveayre@gmail.com>
- prpoxy_media should be proxy_media - bypass_media and proxy_media shouldn't need setting to false - that's their default (unless you're set one of them to true on the sip profile?) - why do you need to disable q850 reason?
I do something very similar - try this...
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
By the way, you'll be unable to rewrite the hangup cause for a bridge that gets a 180 or 183 packet from the gateway before getting a 4xx, 5xx or 6xx packet (because those bridges don't 'fail') - I've seen this on a SIP provider before who gives 183 Session Progress before a 404 Not Found if the PSTN number dialled doesn't exist.
Regards, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Here you go:
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$" break="on-true"> <action inline="true" application="set" data="bypass_media=false"/> <action inline="true" application="set" data="prpoxy_media=false"/> <action inline="true" application="set" data="disable_q850_reason=true"/> <action inline="true" application="set" data="hangup_after_bridge=false"/> <action inline="true" application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action inline="true" application="set" data="bridge_hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action inline="true" application="set" data="hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action application="bridge" data="error/normal_circuit_congestion"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
As you can see, I am trying to rewrite the hangup codes in a multitude of ways and places, but still exhibit the same behaviour.
Any help appreciated.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
Can you show us the dialplan extension you're trying?
Thanks, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote:
Dear All,
I posted a thread re the subject but didn't get any joy, so perhaps second time lucky.
I need to rewrite a couple of hangup causes to mean
NORMAL_CONGESTION
and no matter which variables I set, this isn't happening. The idea is to control what codes are returned to an end point after a successful bridge, as well as deal with what codes are returned if the bridge is unsuccessful (e.g. user_busy, originator_cancel ...etc).
I've had limited success by setting hangup_after_bridge=false then bridging to error/<required_code>. This, however only works when the B-leg terminates the call after a successful answer. Any other codes are not rewritten.
I've also tried playing with the bridge_hangup_code and hangup_code variables prior and after bridging, still no joy. I have also set sip_ignore_remote_cause=true prior to entering the bridge, as well explicitly in vars.xml.
By the way, I'm running in proxy-media mode, but I did try it with bypass-media as well. Same symptoms, same behaviour.
Any help with this would be highly appreciated.
Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
"I wonder if it's possible to rewrite causes from such bridges by executing a JS or similar app attached to the bridge. I'll report on this as and when." If you run a LUA (or JS, etc) script where the hangup app currently is, then you'll be able to check the current hangup cause at that point within the script and conditionally run the hangup app from your script with the cause you want to rewrite to. -Steve 2010/1/13 Ahmed Naji <a.alalousi@gmail.com>:
Steve/All,
Thanks for all your feedback, this thread can be closed.
Here is some feedback:
Re: Steve's queries:
- "pproxy" was a typo on my part, but it should not affect anything. I set them both to false in vars.xml, and don't over-ride them anywhere. - true re: default values for proxy_media & bypass_media being false. I am explicitly setting them here out of 1) paranoia and 2) I like to make sure I know my variable values and not leave them to defaults - relics of being a developer - I was disabling the q850 code as part of my attempts to crack this nut.
Re: the solution, I've managed to rewrite some of the codes with a call to the hangup app, which is what Steve is also using, and his findings re: bridges getting 183 and 180 before 4xx.
I wonder if it's possible to rewrite causes from such bridges by executing a JS or similar app attached to the bridge. I'll report on this as and when.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
- prpoxy_media should be proxy_media - bypass_media and proxy_media shouldn't need setting to false - that's their default (unless you're set one of them to true on the sip profile?) - why do you need to disable q850 reason?
I do something very similar - try this...
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$"> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
By the way, you'll be unable to rewrite the hangup cause for a bridge that gets a 180 or 183 packet from the gateway before getting a 4xx, 5xx or 6xx packet (because those bridges don't 'fail') - I've seen this on a SIP provider before who gives 183 Session Progress before a 404 Not Found if the PSTN number dialled doesn't exist.
Regards, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Here you go:
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$" break="on-true"> <action inline="true" application="set" data="bypass_media=false"/> <action inline="true" application="set" data="prpoxy_media=false"/> <action inline="true" application="set" data="disable_q850_reason=true"/> <action inline="true" application="set" data="hangup_after_bridge=false"/> <action inline="true" application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action inline="true" application="set" data="bridge_hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action inline="true" application="set" data="hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action application="bridge" data="error/normal_circuit_congestion"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
As you can see, I am trying to rewrite the hangup codes in a multitude of ways and places, but still exhibit the same behaviour.
Any help appreciated.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
Can you show us the dialplan extension you're trying?
Thanks, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org>
On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com> wrote: > > Dear All, > > I posted a thread re the subject but didn't get any joy, so perhaps > second time lucky. > > I need to rewrite a couple of hangup causes to mean > NORMAL_CONGESTION > and > no matter which variables I set, this isn't happening. The idea is > to > control what codes are returned to an end point after a successful > bridge, > as well as deal with what codes are returned if the bridge is > unsuccessful > (e.g. user_busy, originator_cancel ...etc). > > I've had limited success by setting hangup_after_bridge=false then > bridging to error/<required_code>. This, however only works when > the > B-leg > terminates the call after a successful answer. Any other codes are > not > rewritten. > > I've also tried playing with the bridge_hangup_code and hangup_code > variables prior and after bridging, still no joy. I have also set > sip_ignore_remote_cause=true prior to entering the bridge, as well > explicitly in vars.xml. > > By the way, I'm running in proxy-media mode, but I did try it with > bypass-media as well. Same symptoms, same behaviour. > > Any help with this would be highly appreciated. > Well, I do know that when you do a hangup in the dialplan you can pass an optional cause as well: <action application="hangup" data="USER_BUSY"/> If you are doing the hanging up then you have a fair amount of control... -MC
_______________________________________________ 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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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
Precisely my line of thought Steve. I'm almost done with a LUA to do the call setup/tare-down and manipulate hangup causes as needed. While I'm at it, I think I may as well handle codec prefs ...etc. within the same script. Will let you and the others how things progress. BR, Ahmed. 2010/1/13 Steven Ayre <steveayre@gmail.com>
"I wonder if it's possible to rewrite causes from such bridges by executing a JS or similar app attached to the bridge. I'll report on this as and when."
If you run a LUA (or JS, etc) script where the hangup app currently is, then you'll be able to check the current hangup cause at that point within the script and conditionally run the hangup app from your script with the cause you want to rewrite to.
-Steve
2010/1/13 Ahmed Naji <a.alalousi@gmail.com>:
Steve/All,
Thanks for all your feedback, this thread can be closed.
Here is some feedback:
Re: Steve's queries:
- "pproxy" was a typo on my part, but it should not affect anything. I set them both to false in vars.xml, and don't over-ride them anywhere. - true re: default values for proxy_media & bypass_media being false. I am explicitly setting them here out of 1) paranoia and 2) I like to make sure I know my variable values and not leave them to defaults - relics of being a developer - I was disabling the q850 code as part of my attempts to crack this nut.
Re: the solution, I've managed to rewrite some of the codes with a call to the hangup app, which is what Steve is also using, and his findings re: bridges getting 183 and 180 before 4xx.
I wonder if it's possible to rewrite causes from such bridges by executing a JS or similar app attached to the bridge. I'll report on this as and when.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
- prpoxy_media should be proxy_media - bypass_media and proxy_media shouldn't need setting to false - that's their default (unless you're set one of them to true on the sip profile?) - why do you need to disable q850 reason?
I do something very similar - try this...
<condition field="destination_number"
expression="^(?:5824)(44(1|2)\d+)$">
<action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
By the way, you'll be unable to rewrite the hangup cause for a bridge that gets a 180 or 183 packet from the gateway before getting a 4xx, 5xx or 6xx packet (because those bridges don't 'fail') - I've seen this on a SIP provider before who gives 183 Session Progress before a 404 Not Found if the PSTN number dialled doesn't exist.
Regards, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Here you go:
<condition field="destination_number" expression="^(?:5824)(44(1|2)\d+)$" break="on-true"> <action inline="true" application="set" data="bypass_media=false"/> <action inline="true" application="set" data="prpoxy_media=false"/> <action inline="true" application="set" data="disable_q850_reason=true"/> <action inline="true" application="set" data="hangup_after_bridge=false"/> <action inline="true" application="set" data="sip_ignore_remote_cause=true"/> <action application="bridge" data="sofia/gateway/sip.xx.xx.com/$1 "/> <action inline="true" application="set" data="bridge_hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action inline="true" application="set" data="hangup_cause=NORMAL_CIRCUIT_CONGESTION"/> <action application="bridge" data="error/normal_circuit_congestion"/> <action application="hangup" data="NORMAL_CIRCUIT_CONGESTION"/> </condition>
As you can see, I am trying to rewrite the hangup codes in a multitude of ways and places, but still exhibit the same behaviour.
Any help appreciated.
Regards,
Ahmed.
2010/1/12 Steven Ayre <steveayre@gmail.com>
Can you show us the dialplan extension you're trying?
Thanks, -Steve
2010/1/12 Ahmed Naji <a.alalousi@gmail.com>:
Hi Michael,
This is exactly what I'm doing, but it's just not happening.
Thanks,
Ahmed.
2010/1/12 Michael Collins <msc@freeswitch.org> > > > On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi@gmail.com
> wrote: >> >> Dear All, >> >> I posted a thread re the subject but didn't get any joy, so perhaps >> second time lucky. >> >> I need to rewrite a couple of hangup causes to mean >> NORMAL_CONGESTION >> and >> no matter which variables I set, this isn't happening. The idea is >> to >> control what codes are returned to an end point after a successful >> bridge, >> as well as deal with what codes are returned if the bridge is >> unsuccessful >> (e.g. user_busy, originator_cancel ...etc). >> >> I've had limited success by setting hangup_after_bridge=false then >> bridging to error/<required_code>. This, however only works when >> the >> B-leg >> terminates the call after a successful answer. Any other codes are >> not >> rewritten. >> >> I've also tried playing with the bridge_hangup_code and hangup_code >> variables prior and after bridging, still no joy. I have also set >> sip_ignore_remote_cause=true prior to entering the bridge, as well >> explicitly in vars.xml. >> >> By the way, I'm running in proxy-media mode, but I did try it with >> bypass-media as well. Same symptoms, same behaviour. >> >> Any help with this would be highly appreciated. >> > Well, I do know that when you do a hangup in the dialplan you can > pass > an > optional cause as well: > <action application="hangup" data="USER_BUSY"/> > If you are doing the hanging up then you have a fair amount of > control... > -MC > > > _______________________________________________ > 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 >
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
_______________________________________________ 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-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
-- Ahmed Naji
participants (4)
-
Ahmed Naji
-
Michael Collins
-
Russell Mosemann
-
Steven Ayre