[Freeswitch-users] Help rewriting hangup causes

Steven Ayre steveayre at gmail.com
Wed Jan 13 06:25:32 PST 2010


"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 at 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 at 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 at 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 at gmail.com>
>> >>
>> >> Can you show us the dialplan extension you're trying?
>> >>
>> >> Thanks,
>> >> -Steve
>> >>
>> >> 2010/1/12 Ahmed Naji <a.alalousi at 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 at freeswitch.org>
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 11, 2010 at 4:18 AM, Ahmed Naji <a.alalousi at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>




More information about the FreeSWITCH-users mailing list