[Freeswitch-users] Help rewriting hangup causes

Wed Jan 13 07:13:09 PST 2010

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 at 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 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
> >
> >
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100113/d06000ae/attachment-0002.html 