new/old server issue

[bcddd214]

I did basically a dd (disk duplicate) migration of a vicidial server, so the only thing I should of had to do was switch the ip, right? after migration and changing this IP, I get this error -> WARNING[17702]: app_meetme.c:3145 admin_exec: Conference number '8600051' not found!

Why can't I find my conference numbers?
I get a conference error when I dial too.

[2013-03-02 02:14:01] Found
[2013-03-02 02:14:01] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:01] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:01] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:03] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:06] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:14:06] Found
[2013-03-02 02:14:06] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:06] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:09] == Refreshing DNS lookups.
[2013-03-02 02:14:15] -- Unregistered SIP 'cc100'
[2013-03-02 02:14:15] -- Registered SIP 'cc101' at 70.170.89.121 port 36201
[2013-03-02 02:14:15] -- Saved useragent "X-Lite release 5.0.0 stamp 67285" for peer cc101
[2013-03-02 02:14:15] NOTICE[3393]: chan_sip.c:14021 handle_response_peerpoke: Peer 'cc101' is now Reachable. (31ms / 2000ms)
[2013-03-02 02:14:20] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:14:20] Found
[2013-03-02 02:14:20] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:14:20] Found
[2013-03-02 02:14:20] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:20] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:20] -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-0ba8,2", "8600051|K") in new stack
[2013-03-02 02:14:20] WARNING[17308]: app_meetme.c:3145 admin_exec: Conference number '8600051' not found!
[2013-03-02 02:14:20] -- Executing [55558600051@default:2] Hangup("Local/55558600051@default-0ba8,2", "") in new stack
[2013-03-02 02:14:20] == Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-0ba8,2'
[2013-03-02 02:14:20] -- Executing [h@default:1] DeadAGI("Local/55558600051@default-0ba8,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[2013-03-02 02:14:20] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[2013-03-02 02:14:22] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:14:22] Found
[2013-03-02 02:14:22] == Manager 'sendcron' logged on from 127.0.0.1
[2013-03-02 02:14:24] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:24] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:27] > Channel SIP/cc101-00000008 was answered.
[2013-03-02 02:14:27] -- Executing [8600051@default:1] MeetMe("SIP/cc101-00000008", "8600051|F") in new stack
[2013-03-02 02:14:27] == Manager 'sendcron' logged off from 127.0.0.1
[2013-03-02 02:14:27] == Parsing '/etc/asterisk/meetme.conf': [2013-03-02 02:14:27] Found
[2013-03-02 02:14:27] == Parsing '/etc/asterisk/meetme-vicidial.conf': [2013-03-02 02:14:27] Found
[2013-03-02 02:14:27] WARNING[17330]: app_meetme.c:829 build_conf: Unable to open DAHDI pseudo device
[2013-03-02 02:14:27] -- <SIP/cc101-00000008> Playing 'conf-invalid' (language 'en')
[2013-03-02 02:14:31] == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/cc101-00000008'
[2013-03-02 02:14:31] -- Executing [h@default:1] DeadAGI("SIP/cc101-00000008", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[2013-03-02 02:14:31] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[2013-03-02 02:15:02] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:15:02] == Parsing '/etc/asterisk/manager.conf': [2013-03-02 02:15:02] Found

[bcddd214]

asterisk 'does' find the ,eetme.conf which does have that meetme room present and confugured, but vicidial chokes on the processing.
This exact server runs fine on a it's old IP.

[bcddd214]

[root@oh ~]# cat /etc/asterisk/meetme.conf
[rooms]
conf => 8600
conf => 8601,1234
#include meetme-vicidial.conf

[root@oh ~]# head /etc/asterisk/meetme-vicidial.conf
; WARNING- THIS FILE IS AUTO-GENERATED BY VICIDIAL, ANY EDITS YOU MAKE WILL BE LOST
; ViciDial Conferences:
conf => 8600051
conf => 8600052
conf => 8600053
conf => 8600054
conf => 8600055
conf => 8600056
conf => 8600057




******************************************
I am a little confused to why '#include meetme-vicidial.conf' is commented out, but I have verified that asterisk finds and processes meetme-vicidial.conf and as you can see, what the call is choking on is the very first entry.

[williamconley]

; is a comment out in asterisk .conf files, not #, so it'd not commented out.
but if you had to perform any other mods to the OS to make it run, you may have changed your kernel in which case your dahdi devices no longer work (until you recompile for the new kernel). A simple way to check is to dial 8600051 from a registered phone. No dahdi = can't get to the meetme room. I suspect this can also happen if your hardware is not precisely identical to the prior system (ie: motherboard change=bad!).

and considering the fact that it does say "Unable to open DAHDI pseudo device", it is entirely possible that your dahdi is just broken. There are instructions for recompiling dahdi on the vicidial wiki and the goauto wiki, but it's basically just a matter of reinstalling dahdi/libpri/asterisk and recompiling them in the proper order. Just like a fresh install for those apps.

Of course, if you merely installed on the new machine from Vicibox 4.0.3 and then dropped the "fresh" db, loaded the "old" db, and then upgraded the DB (with instructions from the UPGRADE doc), you'd have a functional system AND it would be the latest available version. Cool new toys.

oh: nwbie suggestions ...

when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

Happy Hunting!

[bcddd214]

The cloud is linode to be exact.
dahdi is hardware, this ia a pure sip enviroment.
Is vicidial dahdi dependent?

Yes the is dahdi errors, I am trying to load a kernel now, but dahdi typically refers to hardware and just a NIC here.

[bcddd214]

installation method -> http://library.linode.com/migration/mig ... -to-linode
I ran the update_server_ip script as well

[bcddd214]

it is centos with asterisk 1.4 vicidial 2.2.1-237

[williamconley]

The cloud is linode to be exact.
dahdi is hardware, this ia a pure sip enviroment.
Is vicidial dahdi dependent?

Yes the is dahdi errors, I am trying to load a kernel now, but dahdi typically refers to hardware and just a NIC here.

dahdi is not hardware only. the dahdi dummy is now built in (unlike the zt_dummy), but it relies on direct access to the kernel to run. the _dummy version is the software driver version of the normally hardware-provided dahdi system. dummy is not as reliable as hardware, but then again I've not experienced any issues with its reliability in several years, so I'm not entirely sure about that.

fyi: vicidial does not run in virtual environments under any stress. we use vicidial in virtual for testing, max one call. there are those who will try to run it ... but no one who actually has an enterprise system will even consider it and those who do try generally spend more time/energy virtualizing vicidial than they do ... selling their product.

[bcddd214]

I don't know about vicidial but asterisk performs beautifully under a linode/virtualized environment.
Especially when recording calls in one country and bouncing them to another.

[bcddd214]

btw, how do you stress a super computer?
Linode does 50 box clusters.

[williamconley]

I do know about vicidial and asterisk both. Yes, asterisk runs very nicely in a virtual environment. No, vicidial does not. We've built several servers in AWS for clients using dahdi/meetme in asterisk, no problems at all. But the same is not true for Vicidial. It's about the way the code executes, apparently. The vicidial perl scripts are not happy when virtual happens. But: If you think you have a method that will work, feel free to take a shot at it! I'd love to hear of a virtual vici that actually works.

Well, without cutting productivity in half that is ... we've had those who will use an entire core2quad to put 10 agents on ... in one virtual machine. Problem with that scenario is that you can get 25 agents on that same server when NOT virtual. Not entirely useful, that. And even 10 agents could not hold a "load" worthy of note, and you couldn't run another instance on the same box ... so ....