Scott Lawrence wrote:
On Thu, 2009-06-11 at 14:47 -0700, Chris St Denis wrote:
Scott Lawrence wrote:
On Thu, 2009-06-11 at 13:47 -0700, Chris St Denis wrote:
Scott Lawrence wrote:
On Thu, 2009-06-11 at 11:15 -0700, Chris St Denis wrote:
(resending this because it hasn't gotten a reply, and I see it tagged as
spam so it may have gotten filtered for most people)
I've installed 2 sipx 4.0 servers.
pbx1.smartt.com - master server, fully configured .
pbx3.smartt.com - slave server, joined with sipxecs-setup
However, Job status shows replication is failing. Seems to be SSL
errors, but the sipxecs-setup seems to copy over the certs and keystore
so I don't know why it would have SSL issues.
Is this a bug, or did I miss some important step? I haven't been able to
find any documentation on sipx4 replication (all I can find it 3.x which
seems pretty different) so I'm just going by the info in the sidebar on
the add a server page on the master.
Here are some logs from the master of the failures:
http://pastebin.ca/1453932
What specific build are you using?
Server is running sipXconfig (4.0.0-015321)
It's very likely that your problem is fixed in the 4.0.1 builds. You
can either upgrade to the most recent one in the Developer Builds area
(be careful - you want 4.0.1, not 4.1.0), or wait a bit until we copy
it to the stable area (almost certainly tomorrow, by the way)
Thanks. I'll try a yum update tomorrow and see what happens.
Hopefully that will fix my other problems too -- I've been getting
weird database errors in the log (despite the web interface working
fine so it's not a complete database failure)
==> sipxcallresolver.log <==
"2009-06-11T11:15:16.982670 ":ERR:Loss of connection to
database - retrying to connect after sleep
==> sipxstunnel.log <==
2009.06.11 11:15:16 LOG5[4558:3086637968]: Postgres-1
connected from 127.0.0.1:47880
2009.06.11 11:15:16 LOG3[4558:3086637968]: connect_wait:
getsockopt: Connection refused (111)
2009.06.11 11:15:16 LOG5[4558:3086637968]: Connection reset: 0
bytes sent to SSL, 0 bytes sent to socket
And the ability of phones to register has stopped working as well
sometime after I added the replication.
[Phone to pbx]
REGISTER sip:pbx1.smartt.com SIP/2.0.
<snip>
[pbx to phone]
SIP/2.0 100 Trying.
<snip>
[pbx to phone]
SIP/2.0 408 Request timeout.
Not sure if these are related to the replication problems, or even to
eachother.
They are related.
Basically, my advise is that you get the replication working reliably
before you do _anything_ else. Don't configure phones, don't try to use
anything. I know that sounds drastic, but unless you have good reliable
distributed management, many features are going to be very flakey. It's
not true that a stable system can't tolerate network outages between
systems - it can, but you can't get a system to be stable in the first
place without the replication working.
Our network is stable -- The 2 servers are in the same data center and
in the same subnet. The replication is wanted mainly for high
availability/failover in case of hardware failure, and to minimize the
disruption if the main server has to be taken down for hardware changes.
I have already created all the phones and users, so I really hope it
will be able to replicate over the data. It looks like the master
generates the xml files then simply copies them over to the slave and
restart is so it seems like it should be fine to add/remove replication
slaves at any time. Tho there is probably more complexity than I see.
The information I have read seems to be a little unclear about what can
be replicated. The page with server roles suggests only sip routing can
be replicated, and some things I have read suggest that even
registrations aren't replicated/slave can't handle registrations.
Weather voicemail can be replicated also seems to be unclear. If the
main server fails, does voicemail work fully, stop working entirely, or
accept new messages, but not replicate them? Will the auto attendant
work on the backup server?
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
