hangup cause / sip cause ?
Hi i've wrote some dialplans for billing with this great engine which is freeswitch and i'm also using limits and failover ('manually', without the lcr module). Everything works ok and i'm impressed by its stability and performance ! But i'm unable to get a 'final' termination cause for the calls as i'm used to get with asterisk: i'd like to have something like 'answered', 'cancel', 'busy', 'congestion', 'chanunavail', and so on so i'm writing last_bridge_hangup_cause, bridge_hangup_cause and hangup_cause in my cdr and in particular when the call goes thru the second or third trunk (when using failover) i get 'NORMAL_TEMPORARY_FAILURE', 'NORMAL_TEMPORARY_FAILURE', 'NORMAL_CLEARING' and i don't know which one of the three is the actual termination cause :) what are you guys using to get 'consistent' tc ?
On 02/08/2019 15:51, morbidus@rx900.org wrote:
Hi i've wrote some dialplans for billing
Hi! What are you writing the dialplans in? Are you doing billing in a hangup hook? I've noticed that when I bridge to two EPs, right after the bridge, (in my python dialplan) last_bridge_hangup_cause has the hup cause of the first EP, (that failed) while in the hangup hook, last_bridge_hangup_cause has the "correct" value, that is to say, the one from the EP that connected. Hope it helps. k/
Hi Keith thanks for the info, I'm using the vanilla 'xml dialplan', do you think there is something similar (an hangup hook) when not using python nor lua ? Thank you, Mike On Sat, 3 Aug 2019 18:36:24 +0200 Keith <keith@rhizomatica.org> wrote:
On 02/08/2019 15:51, morbidus@rx900.org wrote:
Hi i've wrote some dialplans for billing
Hi!
What are you writing the dialplans in?
Are you doing billing in a hangup hook?
I've noticed that when I bridge to two EPs, right after the bridge, (in my python dialplan)
last_bridge_hangup_cause has the hup cause of the first EP, (that failed)
while in the hangup hook, last_bridge_hangup_cause has the "correct" value, that is to say, the one from the EP that connected.
Hope it helps.
k/
On 02/08/2019 15:51, morbidus@rx900.org wrote:
But i'm unable to get a 'final' termination cause for the calls as i'm used to get with asterisk: i'd like to have something like 'answered', 'cancel', 'busy', 'congestion', 'chanunavail', and so on
Can you also check whether originate_disposition, (and maybe endpoint_disposition) contain the info you want?
so i'm writing last_bridge_hangup_cause, bridge_hangup_cause and hangup_cause in my cdr
I'm wondering now. Is last_bridge_hangup_cause in the CDR the "correct" one, verified by your knowledge of what actually happened? You /could/ run a hangup hook from XML dialplan, but I think you need to run some lua, could be inline lua.. but you can print the value of a variable and check it against what you are seeing in your CDR? something along the lines of: https://lists.freeswitch.org/pipermail/freeswitch-users/2011-August/075103.h...
Thank you all for the help and sorry for the late reply, I did some tests with originate_disposition and endpoint_disposition. ${originate_disposition} looks good in a 'controlled environment' with my asterisks and my dialplans but then it gets quirky when dealing with the real trunk. But it's the trunk's fault: they do all sorts of failovers and retries with a single call and the result is a messy TC. So for now I'm adding originate_disposition to my cdr and i'll add some code to 'guess' the best TC among the various cdr fields. Thank you all and have great holidays :) On Sat, 3 Aug 2019 20:49:49 +0200 Keith <keith@rhizomatica.org> wrote:
On 02/08/2019 15:51, morbidus@rx900.org wrote:
But i'm unable to get a 'final' termination cause for the calls as i'm used to get with asterisk: i'd like to have something like 'answered', 'cancel', 'busy', 'congestion', 'chanunavail', and so on
Can you also check whether originate_disposition, (and maybe endpoint_disposition) contain the info you want?
so i'm writing last_bridge_hangup_cause, bridge_hangup_cause and hangup_cause in my cdr
I'm wondering now. Is last_bridge_hangup_cause in the CDR the "correct" one, verified by your knowledge of what actually happened?
You /could/ run a hangup hook from XML dialplan, but I think you need to run some lua, could be inline lua.. but you can print the value of a variable and check it against what you are seeing in your CDR?
something along the lines of: https://lists.freeswitch.org/pipermail/freeswitch-users/2011-August/075103.h...
Are you returning from the bridge to the dialplan for further processing? Perhaps the b-leg fails with NORMAL_TEMPORARY_FAILURE, returns to dialplan, and then you're hanging the a-leg up with NORMAL_CLEARING when it reaches the end of the dialplan? Which would mean the Reason header sent on the a-leg would indicate NORMAL_CLEARING. On Sat, 3 Aug 2019 at 17:28, morbidus@rx900.org <morbidus@rx900.org> wrote:
Hi i've wrote some dialplans for billing with this great engine which is freeswitch and i'm also using limits and failover ('manually', without the lcr module).
Everything works ok and i'm impressed by its stability and performance !
But i'm unable to get a 'final' termination cause for the calls as i'm used to get with asterisk: i'd like to have something like 'answered', 'cancel', 'busy', 'congestion', 'chanunavail', and so on
so i'm writing last_bridge_hangup_cause, bridge_hangup_cause and hangup_cause in my cdr and in particular when the call goes thru the second or third trunk (when using failover) i get 'NORMAL_TEMPORARY_FAILURE', 'NORMAL_TEMPORARY_FAILURE', 'NORMAL_CLEARING' and i don't know which one of the three is the actual termination cause :)
what are you guys using to get 'consistent' tc ? _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://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 https://freeswitch.com
participants (3)
-
Keith
-
morbidus＠rx900.org
-
Steven Ayre