Remote agent problem with vicibox 8.1.2

[dspaan]

I upgraded a vicibox 8.01. server to 8.1.2 with svn 3053 and now when an inbound call goes to a remote agent the phone rings but when you answer it is disconnected. Here is the output:

Code: Select all

[Dec 21 18:46:50]     -- Executing [138331*115*Y2211846440000545829*2000*@default:1] AGI("Local/077*255*255*255*531censored@default-000000d1;1", "agi-VDAD_local_optimize.agi,") in new stack
[Dec 21 18:46:50]     -- Launched AGI Script /usr/share/asterisk/agi-bin/agi-VDAD_local_optimize.agi
[Dec 21 18:46:50]     -- Channel SIP/brightline_220453-000000bb joined 'simple_bridge' basic-bridge <251aa5c1-f53e-4bc5-9696-8fb13cc68f30>
[Dec 21 18:46:50]     -- Channel Local/255*255*255*255*531censored@default-000000d1;2 joined 'simple_bridge' basic-bridge <251aa5c1-f53e-4bc5-9696-8fb13cc68f30>
[Dec 21 18:46:51]     -- <Local/255*255*255*231*531652585666@default-000000d1;1>AGI Script agi-VDAD_local_optimize.agi completed, returning 0
[Dec 21 18:46:51]     -- Executing [138331*115*Y2211846440000545829*2000*@default:2] Wait("Local/255*255*255*231*531censored@default-000000d1;1", "2") in new stack
[Dec 21 18:46:51]        > 0x7f72900076f0 -- Strict RTP learning complete - Locking on source address 255.255.255.255:14106
[Dec 21 18:46:53]     -- Executing [138331*115*Y2211846440000545829*2000*@default:3] Hangup("Local/255*255*255*255*531censored@default-000000d1;1", "") in new stack
[Dec 21 18:46:53]   == Spawn extension (default, 138331*115*Y2211846440000545829*2000*, 3) exited non-zero on 'Local/077*073*228*231*531censored@default-000000d1;1'
[Dec 21 18:46:53] WARNING[4413][C-000001b7]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel

Any ideas? I can just imagine no one has run into this yet because remote agents are used less.

We tested by changing the DID route to EXTEN or PHONE or Voicemail and that all works fine.

[williamconley]

I upgraded a vicibox 8.01. server to 8.1.2 with svn 3053

Um... You can't "upgrade" Vicibox. You can only install with a newer Vicibox CD (which would then require restoring the DB and upgrading the DB to match the newer version of the Vicidial scripts).

You can upgrade Vicidial without reinstalling the OS and packages, which is an "upgrade", but Vicibox is never an "upgrade" unless you are just using zypper, but that's not going to upgrade Vicibox to a newer version of Vicibox, just the packages that were installed by the original Vicibox to their latest versions (ie: no new packages will be installed, even if the new version of Vicibox has them).

So what exactly did you do to "upgrade"? zypper up? svn up?

[dspaan]

You can only install with a newer Vicibox CD (which would then require restoring the DB and upgrading the DB to match the newer version of the Vicidial scripts).

This is what i meant. I installed a clean vicibox 8.1.2 server then imported the database of a vicibox 8.0.1 server with matching SVN version and ran the server update ip script, changed asterisk version on the server page, rebuild conf=Y.

This server has been used in production for a week now so all is fine except this remote agent part which we only discovered today.
I even reproduced it on a clean vicibox 8.1.2 server and it has the same problem.

[williamconley]

In that case it's likely related to how these calls are being generated. are the numbers local extensions or sip accounts or being reached through a carrier?

[dspaan]

I tested with an external extension for the remote agent and with a local 3 digit extension. Also this problem only applies when you dial inbound to a DID that rings an on hook agent. The outbound campaign for a remote agent works fine.

[williamconley]

this problem only applies when you dial inbound to a DID that rings an on hook agent. The outbound campaign for a remote agent works fine.

in that case "VDAD_local_optimize" vs how are you routing this call? Ordinarily I would expect it to go: DID -> Ingroup -> Agent (agent is logged in to Campaign which has this Ingroup authorized AND remote agent also has this ingroup authorized).

But: If you have some that work and some that don't, it's time to provide a log for each and see where they differ. This may involve cli debug with agi debug and/or sip debug.

[dspaan]

It's only the first case. On this server this was already working before the database was migrated to the new vicibox. We only have one remote agent and indeed the route is DID>Ingroup>Remote agent who is logged onto a dedicated campaign and is an on hook agent with extension 257.

My colleauge also said the call ends with VDAD-local_optimize. I read this was introduced for Asterisk 13. Maybe we have found a bug here? It looks like the call is hungup when answered so a step is skipped in the dialplan.

[williamconley]

Are you using asterisk 13?

[dspaan]

Yes, isnt it the default for vicibox 8.1.2?

[williamconley]

So you have a database that was being used for asterisk 11 which you restored over top of a server with asterisk 13 and then upgraded the DB to the same SVN revision level of that install. But asterisk is behaving badly.

Did you restore anything aside from the DB during your restore process?

Do you have the DB entries for the original installation's server and DB settings?

Or is it your position that the latest version of Vicidial is incapable of calling remote agents, even before you performed the restore?

[dspaan]

I upgraded the database to the same SVN revision of the new vicibox server before i imported it.

I tested with a clean vicibox 8.1.2 installed added a DID, ingroup and remote agent and it had the same problem. So my conclusion was this has nothing to do with the migration i did.

[williamconley]

Your conclusion is based on incorrect logic.

After the full install, do NOT import a database. Instead, simply configure a single agent and run a test.

When you imported the DB, you brought in the system settings and server settings from the old server (along with everything else). This "infects" the new server with the old DB. Test without the infection to determine if this is a bug in the new version instead of merely an incomplete port of your database.

If the stock install, without importing the DB, works properly: import the system settings and server settings into the restored database and see if that resolves your issue.

[dspaan]

But on a stock install without imported database is have the same problem?

[williamconley]

Sorry, I read that wrong. I saw upgraded in the first line and thought it applied to the second. In that case we're back to:

If you have some that work and some that don't, it's time to provide a log for each and see where they differ. This may involve cli debug with agi debug and/or sip debug.

Both tests must be run on the same server. The logs *will* differ at some point, although debugging may be necessary. It may also be necessary to get output from the console of any scripts that are running (in the case of automation initiating part of the sequence). Those consoles are running in screens and most have log files, but not all have debug mode on.

[dspaan]

I did a call on a vicibox 8.0.1 server and another one on stock vicibox 8.1.2 but there are so many differences i wouldn't know where to begin. I guess i'll make a support ticket for this with the vicidial group.

[dspaan]

Michael Cargile from the Vicidial group looked at this today, confirmed it was a bug and is now fixed in SVN trunk 3058. Thanks!!

[williamconley]

Excellent postback. Thanks for getting that resolved.