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