VoIP Mailing List Archives

[mikael at bjerkeland.com]

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-nokia@voip.domain.com (mikael-nokia@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-nokia@voip.domain.com (mikael-nokia@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?

Thanks,
Mikael

[mikael at bjerkeland.com]

El mié, 15-04-2009 a las 17:43 +0200, Mikael Bjerkeland escribió:

[anthony.minessale at g...]

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 <mikael@bjerkeland.com (mikael@bjerkeland.com)> wrote:

[mikael at bjerkeland.com]

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ó:

[mikael at bjerkeland.com]

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ó:

[mikael at bjerkeland.com]

Anthony implemented ${bridge_hangup_cause} in r13065 which has the value
of the last B leg bridge attempt. Works as expected!

The leg_delay_start problem still remains though. It would be great if
someone could do a test to see if leg_delay_start on a leg isn't
honored.


El jue, 16-04-2009 a las 16:36 +0200, Mikael Aleksander Bjerkeland
escribió: