Re: [Freeswitch-users] leg_delay_start not working and hangup_after_bridge=true but not if MEDIA_TIMEOUT hangup cause
turn on the debug option in mod_cdr_csv and you will get something similar
to the info app only at the end of the call
On Thu, Apr 16, 2009 at 3:19 AM, Mikael Aleksander Bjerkeland
mik...@bjerkeland.com wrote:
El mié, 15-04-2009 a las 17:43 +0200, Mikael Bjerkeland escribió:
Hi,
I have two scenarios I'm having trouble figuring out and I'd be happy
if someone could tell me what I'm doing wrong.
1. leg_delay_start=N not working
I am trying to delay the origination of the second leg in a forked
dial with the following:
action application=bridge
data=user/mikael-no...@voip.domain.com
,[leg_delay_start=10]openzap/1/a/99355151/
However the second leg is called at exactly the same time as the first
one. I am away from my testing environment right now, so I'm sorry for
not posting my logs. It appears to me that leg_delay_start is broken
on at least rev 13013.
2. I'd like to stop processing the dialplan after a bridge, but not on
specific hangup causes. If I get a MEDIA_TIMEOUT hangup cause in the
call I'd like to continue in the dialplan. Currently I have the
following:
action application=set data=hangup_after_bridge=true/
action application=set data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@voip.domain.com/
!-- I will only get here if the first bridge is rejected or
TODO: I get a MEDIA_TIMEOUT on it --
action application=bridge data=openzap/1/a/99355151/
Any ideas on how to accomplish this?
I started testing this with the following dialplan:
extension name=mikael-nokia+fallback
condition field=destination_number expression=^503$
action application=set data=hangup_after_bridge=false/
action application=set data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@fs.voip.domain.com/
action application=info/
action application=set data=followme_extension=99355151/
action application=execute_extension
data=post_call_followme_check/
action application=hangup/
/condition
/extension
extension name=post_call_followme_check
condition field=destination_number
expression=^post_call_followme_check$/
condition field=${originate_disposition}
expression=^MEDIA_TIMEOUT|$${continue_on_fail_causes}$
break=on-true
action application=log data=1 Follow me transferring call
because of orig disposition: ${originate_disposition}/
action application=transfer data=${followme_extension}/
/condition
condition
action application=log data=1 Follow me call ended normally
with orig disposition: ${originate_disposition}./
action application=hangup/
/condition
/extension
${originate_disposition} never has the value of MEDIA_TIMEOUT since the
call was answered, which is absolutely correct, so what I am searching
for now is how to get the actual hangup cause. The info app doesn't show
MEDIA_TIMEOUT anywhere, but my logs show this:
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:377
audio_bridge_thread()
sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
ending bridge by request from read function
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:456
audio_bridge_thread() Send signal
sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253[BREAK]
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:452
audio_bridge_thread() BRIDGE THREAD DONE
[sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
]
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:456
audio_bridge_thread() Send signal
sofia/internal/mikael-ek...@fs.voip.domain.com [BREAK]
2009-04-16 10:02:34 [DEBUG] switch_core_state_machine.c:508
switch_core_session_run()
(sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
)
State EXCHANGE_MEDIA going to sleep
2009-04-16 10:02:34 [DEBUG] switch_core_state_machine.c:397
switch_core_session_run()
(sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
)
Running State Change CS_HANGUP
EXECUTE sofia/internal/mikael-ek...@fs.voip.domain.com info()
2009-04-16 10:02:34 [DEBUG] switch_core_state_machine.c:448
switch_core_session_run()
(sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
)
State HANGUP
2009-04-16 10:02:34 [DEBUG] mod_sofia.c:315 sofia_on_hangup() Channel
sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253hanging
up, cause:
MEDIA_TIMEOUT
2009-04-16 10:02:34 [DEBUG] mod_sofia.c:370 sofia_on_hangup() Sending
BYE to
sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253
2009-04-16 10:02:34 [DEBUG] switch_core_state_machine.c:46
switch_core_standard_on_hangup()
sofia/internal/sip:mikael-no...@10.247.3.253sip%3amikael-no...@10.247.3.253Standard
HANGUP, cause:
MEDIA_TIMEOUT
2009-04-16 10:02:34 [DEBUG]
Re: [Freeswitch-users] leg_delay_start not working and hangup_after_bridge=true but not if MEDIA_TIMEOUT hangup cause
Thanks. I just tested and got some more data but it didn't contain any
variable containing MEDIA_TIMEOUT. Perhaps it's not really set anywhere?
variable_hangup_cause and variable_originate_disposition contain
NORMAL_CLEARING and SUCCESS respectively. I need a var which contains
the real reason for the hangup of the bridge, which in this case is
MEDIA_TIMEOUT as you can see from the logs.
El jue, 16-04-2009 a las 07:37 -0500, Anthony Minessale escribió:
turn on the debug option in mod_cdr_csv and you will get something
similar to the info app only at the end of the call
On Thu, Apr 16, 2009 at 3:19 AM, Mikael Aleksander Bjerkeland
mik...@bjerkeland.com wrote:
El mié, 15-04-2009 a las 17:43 +0200, Mikael Bjerkeland
escribió:
Hi,
I have two scenarios I'm having trouble figuring out and I'd
be happy
if someone could tell me what I'm doing wrong.
1. leg_delay_start=N not working
I am trying to delay the origination of the second leg in a
forked
dial with the following:
action application=bridge
data=user/mikael-no...@voip.domain.com,[leg_delay_start=10]openzap/1/a/99355151/
However the second leg is called at exactly the same time as
the first
one. I am away from my testing environment right now, so I'm
sorry for
not posting my logs. It appears to me that leg_delay_start
is broken
on at least rev 13013.
2. I'd like to stop processing the dialplan after a bridge,
but not on
specific hangup causes. If I get a MEDIA_TIMEOUT hangup
cause in the
call I'd like to continue in the dialplan. Currently I have
the
following:
action application=set
data=hangup_after_bridge=true/
action application=set
data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@voip.domain.com/
!-- I will only get here if the first bridge is
rejected or
TODO: I get a MEDIA_TIMEOUT on it --
action application=bridge
data=openzap/1/a/99355151/
Any ideas on how to accomplish this?
I started testing this with the following dialplan:
extension name=mikael-nokia+fallback
condition field=destination_number expression=^503$
action application=set
data=hangup_after_bridge=false/
action application=set
data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@fs.voip.domain.com/
action application=info/
action application=set
data=followme_extension=99355151/
action application=execute_extension
data=post_call_followme_check/
action application=hangup/
/condition
/extension
extension name=post_call_followme_check
condition field=destination_number
expression=^post_call_followme_check$/
condition field=${originate_disposition}
expression=^MEDIA_TIMEOUT|$${continue_on_fail_causes}$
break=on-true
action application=log data=1 Follow me transferring
call
because of orig disposition: ${originate_disposition}/
action application=transfer
data=${followme_extension}/
/condition
condition
action application=log data=1 Follow me call ended
normally
with orig disposition: ${originate_disposition}./
action application=hangup/
/condition
/extension
${originate_disposition} never has the value of MEDIA_TIMEOUT
since the
call was answered, which is absolutely correct, so what I am
searching
for now is how to get the actual hangup cause. The info app
doesn't show
MEDIA_TIMEOUT anywhere, but my logs show this:
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:377
audio_bridge_thread()
sofia/internal/sip:mikael-no...@10.247.3.253
ending bridge by request from read function
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:456
audio_bridge_thread() Send signal
sofia/internal/sip:mikael-no...@10.247.3.253 [BREAK]
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:452
audio_bridge_thread() BRIDGE THREAD DONE
[sofia/internal/sip:mikael-no...@10.247.3.253]
2009-04-16 10:02:34 [DEBUG] switch_ivr_bridge.c:456
audio_bridge_thread() Send signal
Re: [Freeswitch-users] leg_delay_start not working and hangup_after_bridge=true but not if MEDIA_TIMEOUT hangup cause
I think I know a bit more about the problem now. The MEDIA_TIMEOUT
hangup cause is probably coming from the B leg of the call and thus not
visible when I do info or debug on mod_cdr_csv.
I then tried the following after bridge to get it:
action application=set data=other_leg_hangup_cause=
${uuid_getvar(${bridge_uuid} hangup_cause)}/
However, since that bridge of the call is already hung up I got the
following in reply:
variable_other_leg_hangup_cause: [-ERR No Such Channel!
]
Is there a way to get it from the B leg of the call - assuming that's
where the hangup cause comes from?
Thanks!
El jue, 16-04-2009 a las 16:07 +0200, Mikael Aleksander Bjerkeland
escribió:
Thanks. I just tested and got some more data but it didn't contain any
variable containing MEDIA_TIMEOUT. Perhaps it's not really set anywhere?
variable_hangup_cause and variable_originate_disposition contain
NORMAL_CLEARING and SUCCESS respectively. I need a var which contains
the real reason for the hangup of the bridge, which in this case is
MEDIA_TIMEOUT as you can see from the logs.
El jue, 16-04-2009 a las 07:37 -0500, Anthony Minessale escribió:
turn on the debug option in mod_cdr_csv and you will get something
similar to the info app only at the end of the call
On Thu, Apr 16, 2009 at 3:19 AM, Mikael Aleksander Bjerkeland
mik...@bjerkeland.com wrote:
El mié, 15-04-2009 a las 17:43 +0200, Mikael Bjerkeland
escribió:
Hi,
I have two scenarios I'm having trouble figuring out and I'd
be happy
if someone could tell me what I'm doing wrong.
1. leg_delay_start=N not working
I am trying to delay the origination of the second leg in a
forked
dial with the following:
action application=bridge
data=user/mikael-no...@voip.domain.com,[leg_delay_start=10]openzap/1/a/99355151/
However the second leg is called at exactly the same time as
the first
one. I am away from my testing environment right now, so I'm
sorry for
not posting my logs. It appears to me that leg_delay_start
is broken
on at least rev 13013.
2. I'd like to stop processing the dialplan after a bridge,
but not on
specific hangup causes. If I get a MEDIA_TIMEOUT hangup
cause in the
call I'd like to continue in the dialplan. Currently I have
the
following:
action application=set
data=hangup_after_bridge=true/
action application=set
data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@voip.domain.com/
!-- I will only get here if the first bridge is
rejected or
TODO: I get a MEDIA_TIMEOUT on it --
action application=bridge
data=openzap/1/a/99355151/
Any ideas on how to accomplish this?
I started testing this with the following dialplan:
extension name=mikael-nokia+fallback
condition field=destination_number expression=^503$
action application=set
data=hangup_after_bridge=false/
action application=set
data=continue_on_fail=true/
action application=bridge
data=user/mikael-no...@fs.voip.domain.com/
action application=info/
action application=set
data=followme_extension=99355151/
action application=execute_extension
data=post_call_followme_check/
action application=hangup/
/condition
/extension
extension name=post_call_followme_check
condition field=destination_number
expression=^post_call_followme_check$/
condition field=${originate_disposition}
expression=^MEDIA_TIMEOUT|$${continue_on_fail_causes}$
break=on-true
action application=log data=1 Follow me transferring
call
because of orig disposition: ${originate_disposition}/
action application=transfer
data=${followme_extension}/
/condition
condition
action application=log data=1 Follow me call ended
normally
with orig disposition: ${originate_disposition}./
action application=hangup/
/condition
/extension
${originate_disposition} never has the value of MEDIA_TIMEOUT
since the
call was answered, which is absolutely correct, so what I am
