vicidial.org

Hello,

I have just faced problem, which makes Vicibox 3.1.5 and 3.1.6 virtually unusable for us. (We tried to jump into them from 3.0.6) Probably it relates to "asterisk 1.4.38 transfer bug". The problem manifests itself in inbound campaign when one tries to transfer or park calls in Vicidial. These calls are immediately disconnected and lost. Did you see something similar?

Best Wishes,
Gene

Asterisk CLI and / or astguiclient logs from an occurrence?

thanks for posting your version information! (helpful when tracking bugs).

If you can get DETAILED information regarding the occurrence ... and use the Vicidial Issue Tracker ... and post a link to the tracker item here ... you get a much better chance at resolution. especially since you're the type that posted your installer with version AND your vicidial version with build ... (makes you fairly rare!), i bet you could handle that. (and your contribution could actually cause a bug to get squished )

Eugene wrote:Hello,

I have just faced problem, which makes Vicibox 3.1.5 and 3.1.6 virtually unusable for us. (We tried to jump into them from 3.0.6) Probably it relates to "asterisk 1.4.38 transfer bug". The problem manifests itself in inbound campaign when one tries to transfer or park calls in Vicidial. These calls are immediately disconnected and lost. Did you see something similar?

Best Wishes,
Gene

I just updated the Asterisk tarball to use 1.4.39.1, which deals with the hang-up issue on channel redirect (or so the changelog tells me). You should be able to do a 'zypper refresh && zypper up' to pull in the update. Let me know if that fixes the issue for you.

On a side note, we always seem to have the best of luck with those sub-point releases. 1.4.21.2, 1.4.27.1, and now 1.4.39.1. Funny how that works out.

Thank you for the news!

I am afraid that I can not verify Asterisk 1.4.39 at the moment. You see, deadlines and all ... For the last hours we were busy retreating to Vicibox 3.0.6 and finally did that. I simply do not have working Vicibox 3.1.6 system.

Is it still actual to open a bug at Issue Tracker and post Asterisk console logs ?

Best Wishes,
Gene

I have created a new tarball using a newer corrected asterisk source. It's the item listed here for upgrading asterisk:

http://www.vicidial.org/VICIDIALforum/v ... hp?t=15336

Try that and test it, let me know if it fixes the bug in your scenario.

We are experiencing a similar problem on Vicibox 3.1.6 (VERSION: 2.4-296 BUILD: 110111-1305)

We have done zypper refresh/zypper up and now we are running on asterisk 1.4.39.1-vici but problem still remains.

We only do outbound calling and when agent do PARK CALL or PARK CUSTOMER DIAL and then GRAB CALL, everything works fine. The problem occurs when agent do PARK CALL or PARK CUSTOMER DIAL for the second time on the same call.

Steps:
1) Agent gets call from outbound campaign
2) Agent parks the call (with PARK CALL button) --> OK (music on hold is also playing)
3) Agent grabs call (with GRAB CALL button) OK
4) Agent parks call once again (with PARK CALL button) --> Call is HangUp

This happens on each call !


Cli on FIRST PARK CALL

[Feb 3 17:06:39] -- Executing [8301@default:1] Answer("IAX2/10.1.1.19:4569-11310", "") in new stack
[Feb 3 17:06:39] -- Executing [h@default:1] DeadAGI("Local/8600061@default-4491,1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----17-----6") in new stack
[Feb 3 17:06:39] -- Executing [8301@default:2] AGI("IAX2/10.1.1.19:4569-11310", "park_CID.agi") in new stack
[Feb 3 17:06:39] WARNING[1902]: res_agi.c:2212 deadagi_exec: Running DeadAGI on a live channel will cause problems, please use AGI
[Feb 3 17:06:39] == Manager 'sendcron' logged off from 127.0.0.1
[Feb 3 17:06:39] -- Launched AGI Script /var/lib/asterisk/agi-bin/park_CID.agi
[Feb 3 17:06:39] == Parsing '/etc/asterisk/manager.conf': [Feb 3 17:06:39] Found
[Feb 3 17:06:39] == Manager 'sendcron' logged on from 127.0.0.1
[Feb 3 17:06:39] == Spawn extension (default, 8301, 0) exited non-zero on 'Local/8600061@default-4491,2'
[Feb 3 17:06:39] -- Executing [8301@default:1] Answer("Local/8600061@default-4491,2", "") in new stack
[Feb 3 17:06:39] -- Executing [8301@default:2] AGI("Local/8600061@default-4491,2", "park_CID.agi") in new stack
[Feb 3 17:06:39] == Manager 'sendcron' logged off from 127.0.0.1
[Feb 3 17:06:39] -- Launched AGI Script /var/lib/asterisk/agi-bin/park_CID.agi
[Feb 3 17:06:39] == Spawn extension (default, 8301, 2) exited non-zero on 'Local/8600061@default-4491,2'
[Feb 3 17:06:39] -- Executing [h@default:1] DeadAGI("Local/8600061@default-4491,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Feb 3 17:06:39] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Feb 3 17:06:39] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Feb 3 17:06:39] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Feb 3 17:06:39] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Feb 3 17:06:39] -- Started music on hold, class 'parked_calls', on IAX2/10.1.1.19:4569-11310



Cli on FIRST GRAB CALL

[Feb 3 17:08:42] -- Stopped music on hold on IAX2/10.1.1.19:4569-11310
[Feb 3 17:08:42] == Spawn extension (default, 8600061, 0) exited non-zero on 'IAX2/10.1.1.19:4569-11310'
[Feb 3 17:08:42] -- Executing [8600061@default:1] MeetMe("IAX2/10.1.1.19:4569-11310", "8600061|F") in new stack



Cli on SECOND PARK CALL

[Feb 3 17:11:03] == Spawn extension (default, 8301, 0) exited non-zero on 'IAX2/10.1.1.19:4569-11310'
[Feb 3 17:11:03] -- Executing [8301@default:1] Answer("IAX2/10.1.1.19:4569-11310", "") in new stack
[Feb 3 17:11:03] -- Executing [8301@default:2] AGI("IAX2/10.1.1.19:4569-11310", "park_CID.agi") in new stack
[Feb 3 17:11:03] == Manager 'sendcron' logged off from 127.0.0.1
[Feb 3 17:11:03] -- Launched AGI Script /var/lib/asterisk/agi-bin/park_CID.agi
[Feb 3 17:11:03] == Spawn extension (default, 8301, 2) exited non-zero on 'IAX2/10.1.1.19:4569-11310'
[Feb 3 17:11:03] -- Executing [h@default:1] DeadAGI("IAX2/10.1.1.19:4569-11310", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Feb 3 17:11:04] -- Hungup 'IAX2/10.1.1.19:4569-11310'


Anyone else facing the same issue?

Yes,

I am having same problem - please let me know if you got any fix

Don't know what to do else...
Anyone here have some idea?

Is it related to Asterisk 1.4.39.1-vici or what?

This problem did not happen on asterisk 1.4.27.1-vici (for instance on a vicibox 3.0.9). Should/Can I downgrade? How to do it?

if you follow the installation steps (check out the vicidial wiki for asterisk 1.4 installation) you can install asterisk right on top of another asterisk, just be sure it isn't running when you install the new one

I just released a package update that will downgrade you to 1.4.27.1. Just do a zypper refresh and zypper up to install it.

Hey Kumba, just did zypper refresh and zypper up and it installed all sorts of packages (18 in total) but I still have version 1.4.39.1, no asterisk downgrade actually.

Why it doesn't get 1.4.27.1 ???

Following the result of zypper refresh/up:

dialer05:~ # zypper refresh
Retrieving repository 'Packman_11.3' metadata [done]
Building repository 'Packman_11.3' cache [done]
Retrieving repository 'Updates for openSUSE 11.3 11.3-1.82' metadata [done]
Building repository 'Updates for openSUSE 11.3 11.3-1.82' cache [done]
Retrieving repository 'home:vicidial_11.3' metadata [done]
Building repository 'home:vicidial_11.3' cache [done]
Repository 'openSUSE_11.3_OSS' is up to date.
Retrieving repository 'openSUSE_11.3_Updates' metadata [done]
Building repository 'openSUSE_11.3_Updates' cache [done]
Retrieving repository 'openSUSE_BuildService_-_devel:languages:perl' metadata [done]
Building repository 'openSUSE_BuildService_-_devel:languages:perl' cache [done]
Repository 'openSUSE-11.3-Non-Oss' is up to date.
Repository 'openSUSE-11.3-Oss' is up to date.
Retrieving repository 'server:php:extensions_11.3' metadata [done]
Building repository 'server:php:extensions_11.3' cache [done]
All repositories have been refreshed.

dialer05:~ # zypper up
Loading repository data...
Reading installed packages...

The following package updates will NOT be installed:
kernel-default-base liborc-0_4-0 tgt

The following packages are going to be upgraded:
asterisk-woomera dhcp dhcp-relay dhcp-server libavcodec52 libavcore0 libavformat52 libavutil50
perl-CGI-Simple perl-Data-ShowTable perl-IO-String perl-IO-stringy perl-Net-IPv4Addr perl-NetxAP
perl-Params-Validate perl-Parse-RecDescent perl-TimeDate wanpipe

The following package is going to change architecture:
perl-CGI-Simple x86_64 -> noarch


18 packages to upgrade, 1 to change arch.
Overall download size: 5.2 MiB. No additional space will be used or freed after the operation.
Continue? [y/n/?] (y): y
Retrieving package perl-TimeDate-1.20-17.1.noarch (1/18), 44.0 KiB (97.0 KiB unpacked)
Retrieving: perl-TimeDate-1.20-17.1.noarch.rpm [done]
Installing: perl-TimeDate-1.20-17.1 [done]
Retrieving package perl-Parse-RecDescent-1.965001-22.1.noarch (2/18), 93.0 KiB (252.0 KiB unpacked)
Retrieving: perl-Parse-RecDescent-1.965001-22.1.noarch.rpm [done (158.7 KiB/s)]
Installing: perl-Parse-RecDescent-1.965001-22.1 [done]
Retrieving package perl-Params-Validate-0.95-11.1.x86_64 (3/18), 85.0 KiB (226.0 KiB unpacked)
Retrieving: perl-Params-Validate-0.95-11.1.x86_64.rpm [done (46.8 KiB/s)]
Installing: perl-Params-Validate-0.95-11.1 [done]
Retrieving package perl-NetxAP-0.02-1409.1.x86_64 (4/18), 52.0 KiB (135.0 KiB unpacked)
Retrieving: perl-NetxAP-0.02-1409.1.x86_64.rpm [done (88.8 KiB/s)]
Installing: perl-NetxAP-0.02-1409.1 [done]
Retrieving package perl-Net-IPv4Addr-0.10-301.1.x86_64 (5/18), 15.0 KiB (21.0 KiB unpacked)
Retrieving: perl-Net-IPv4Addr-0.10-301.1.x86_64.rpm [done (0 B/s)]
Installing: perl-Net-IPv4Addr-0.10-301.1 [done]
Retrieving package perl-IO-stringy-2.110-292.1.x86_64 (6/18), 63.0 KiB (128.0 KiB unpacked)
Retrieving: perl-IO-stringy-2.110-292.1.x86_64.rpm [done (32.6 KiB/s)]
Installing: perl-IO-stringy-2.110-292.1 [done]
Retrieving package perl-IO-String-1.08-291.1.x86_64 (7/18), 13.0 KiB (18.0 KiB unpacked)
Retrieving: perl-IO-String-1.08-291.1.x86_64.rpm [done (20.3 KiB/s)]
Installing: perl-IO-String-1.08-291.1 [done]
Retrieving package perl-Data-ShowTable-3.3-1431.1.x86_64 (8/18), 51.0 KiB (117.0 KiB unpacked)
Retrieving: perl-Data-ShowTable-3.3-1431.1.x86_64.rpm [done (14.8 KiB/s)]
Installing: perl-Data-ShowTable-3.3-1431.1 [done]
Retrieving package wanpipe-3.5.18-17.3.x86_64 (9/18), 1.4 MiB (4.7 MiB unpacked)
Retrieving: wanpipe-3.5.18-17.3.x86_64.rpm [done (147.9 KiB/s)]
Installing: wanpipe-3.5.18-17.3 [done]
Retrieving package asterisk-woomera-3.5.18-17.3.x86_64 (10/18), 39.0 KiB (94.0 KiB unpacked)
Retrieving: asterisk-woomera-3.5.18-17.3.x86_64.rpm [done]
Installing: asterisk-woomera-3.5.18-17.3 [done]
Retrieving package dhcp-4.1.2.ESV.1-0.2.1.x86_64 (11/18), 216.0 KiB (483.0 KiB unpacked)
Retrieving delta: ./rpm/x86_64/dhcp-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm, 71.0 KiB
Retrieving: dhcp-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done (71.8 KiB/s)]
Applying delta: ./dhcp-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done]
Installing: dhcp-4.1.2.ESV.1-0.2.1 [done]
Retrieving package libavutil50-0.6.26387svn-1.pm.3.2.x86_64 (12/18), 43.0 KiB (87.0 KiB unpacked)
Retrieving: libavutil50-0.6.26387svn-1.pm.3.2.x86_64.rpm [done]
Installing: libavutil50-0.6.26387svn-1.pm.3.2 [done]
Additional rpm output:
warning: /var/cache/zypp/packages/Packman_11.3/x86_64/libavutil50-0.6.26387svn-1.pm.3.2.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 9a795806: NOKEY


Retrieving package perl-CGI-Simple-1.113-21.1.noarch (13/18), 101.0 KiB (223.0 KiB unpacked)
Retrieving: perl-CGI-Simple-1.113-21.1.noarch.rpm [done (33.3 KiB/s)]
Installing: perl-CGI-Simple-1.113-21.1 [done]
Retrieving package dhcp-server-4.1.2.ESV.1-0.2.1.x86_64 (14/18), 387.0 KiB (922.0 KiB unpacked)
Retrieving delta: ./rpm/x86_64/dhcp-server-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm, 141.0 KiB
Retrieving: dhcp-server-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done (45.5 KiB/s)]
Applying delta: ./dhcp-server-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done]
Installing: dhcp-server-4.1.2.ESV.1-0.2.1 [done]
Additional rpm output:
Updating etc/sysconfig/dhcpd...
Updating etc/sysconfig/syslog...


Retrieving package dhcp-relay-4.1.2.ESV.1-0.2.1.x86_64 (15/18), 197.0 KiB (469.0 KiB unpacked)
Retrieving delta: ./rpm/x86_64/dhcp-relay-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm, 54.0 KiB
Retrieving: dhcp-relay-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done (0 B/s)]
Applying delta: ./dhcp-relay-4.1.1.P1_4.1.2.ESV.1-4.3.1_0.2.1.x86_64.delta.rpm [done]
Installing: dhcp-relay-4.1.2.ESV.1-0.2.1 [done]
Additional rpm output:
Updating etc/sysconfig/dhcrelay...


Retrieving package libavcore0-0.6.26387svn-1.pm.3.2.x86_64 (16/18), 15.0 KiB (29.0 KiB unpacked)
Retrieving: libavcore0-0.6.26387svn-1.pm.3.2.x86_64.rpm [done]
Installing: libavcore0-0.6.26387svn-1.pm.3.2 [done]
Additional rpm output:
warning: /var/cache/zypp/packages/Packman_11.3/x86_64/libavcore0-0.6.26387svn-1.pm.3.2.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 9a795806: NOKEY


Retrieving package libavcodec52-0.6.26387svn-1.pm.3.2.x86_64 (17/18), 2.0 MiB (5.3 MiB unpacked)
Retrieving: libavcodec52-0.6.26387svn-1.pm.3.2.x86_64.rpm [done (125.3 KiB/s)]
Installing: libavcodec52-0.6.26387svn-1.pm.3.2 [done]
Additional rpm output:
warning: /var/cache/zypp/packages/Packman_11.3/x86_64/libavcodec52-0.6.26387svn-1.pm.3.2.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 9a795806: NOKEY


Retrieving package libavformat52-0.6.26387svn-1.pm.3.2.x86_64 (18/18), 387.0 KiB (951.0 KiB unpacked)
Retrieving: libavformat52-0.6.26387svn-1.pm.3.2.x86_64.rpm [done (101.2 KiB/s)]
Installing: libavformat52-0.6.26387svn-1.pm.3.2 [done]
Additional rpm output:
warning: /var/cache/zypp/packages/Packman_11.3/x86_64/libavformat52-0.6.26387svn-1.pm.3.2.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 9a795806: NOKEY

I just found some more asterisk redirect bugs that were patched up around the end of January. This time they are specifically related to meetme and redirect. I've added them to the 1.4.39.1 build and recompiled it. You can pull them in by following the "Call Transfer and Park Bug" instructions in this thread: http://www.vicidial.org/VICIDIALforum/v ... hp?t=15336

So far, we have placed an outbound dial on our test system, parked the call, then picked it up, then re-parked it, and pick up, and so on, about 30 times without hangup. We have also tested an inbound call to the agent in a similar manner.

It looks like we may finally be good to go, until the next thing breaks in Asterisk.

Now it works !!!

Thanks kumba and all of you guys there for your precious support !

hi kumba ,

thanks for providing a patch for this , i too faced the same issue.

unfortunately my server is behind a proxy and am not able to do the below steps

--------------------------------------------------
Call transfer and park bug (v.3.1.6 and under), this will upgrade you to 1.4.39.1-vici:
1) /etc/init.d/vicidial stop
2) zypper refresh
3) zypper up
4) /etc/init.d/vicidial start
---------------------------------------------------

Is it possible to manually apply the patch provided ?

Thanks
Shiju

ViciBox Server v.3.1 from ViciBox_Redux.i686-3.1.3.iso| Vicidial VERSION: 2.2.1-237 BUILD: 100510-2015| Asterisk 1.4.38 | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation

You can try to manually download the file from the repository. But if that wouldn't work with zypper, I doubt that wget will work since they go to the same place in the same manner. The real solution would be to give your machine access to the internet.

The only other option is to download 3.1.8 and reinstall.

OR (the hard way) follow the manual installation instructions for that version of asterisk, downloading the sources/binaries to another machine and transferring them over the local network.

OR (the harder way) set up a parallel repository on your LOCAL network and tell your server to use THAT as a repository instead of Kumbas.

Hi all ,

I was able to do a zypper up and it resolved my call transfer issue.
Now transfer is working smoothly without any issues.

I have documented the steps to 'zypper up' behind a proxy server @ http://www.vicidial.org/VICIDIALforum/v ... hp?t=16609

Thanks to kumba and williamconley for their great support

excellent postback by the way. beautiful.