[Asterisk-Users] Clustering "NEW THREAD", Almost Working

Tue Mar 14 08:18:06 MST 2006

Now, I know what you guys been talking about. It is like DSN for sip
phones, not really clustering. I original thought that you guys want to
setup some thing that can fail over to a different sip server if the
server running the IVR dies.

 From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Douglas
Garstang
Sent: Tuesday, March 14, 2006 12:11 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: RE: [Asterisk-Users] Clustering "NEW THREAD", Almost Working

Holy crap. You got SIP realtime working? I've tried it twice before and
it failed the same way twice. Do you have multiple Asterisk boxes
accessing the same sip info (ie phones) in the same table on the same
database? Digium has said numerous times this known not to work,
although I cant' work out why as it's just reading from a common table.

	-----Original Message----- 
	From: JR Richardson [mailto:jr.richardson at cox.net] 
	Sent: Mon 3/13/2006 7:11 PM 
	To: asterisk-users at lists.digium.com 
	Cc: 
	Subject: [Asterisk-Users] Clustering "NEW THREAD", Almost
Working

	All,

	I made some progress, but it seems the further I go with
clustering the
	harder things get.  Hmmm, I guess if it were easy, it would be
	documented......

	Anyhow, I have 1 * server as the DUNDi peering master with a
ttl=1.  The
	only function of this server is to lookup where other sip peers
are
	registered and forward that info on to the requesting * server.

	I have 4 * servers accepting registrations from sip users
(phones).  All the
	sip phone info is stored in a MySQL database and being accessed
through the
	realtime engine, and it works great.  A phone registers to a
server and the
	server checks the database and if an entry is present, the *
servers allows
	the phone to register and dumps the sip phone into sip show
peers, works
	great.  I can take the sip entry out of the database and the
phone will not
	resister in realtime.  Works great.

	Now the dial plan setup.  All the extension info is also in the
MySQL
	database, I have a switch statement in the [siptest] context
pointing to the
	database for extension logic.  This also works great.  All
servers are
	pointing to the same data source with all sip extensions in the
database
	starting with
	exten => 1234,2,Answer and so on
	exten => 1235,2,Answer and so on

	notice the priority 2 starting point in the database, very
important.

	This is the good part, in sip.conf, I have regcontext=siptest in
the general
	section (because it doesn't work in the users section), so when
a sip phone
	registers on a server, * dynamically inputs an exten =>
1234,1,Noop into the
	dialplan and immediately the phone is able to be called.  This
is working
	pretty damn well also.

	So at this point I have several phones registered across 4 *
servers, all
	pulling their info from MySQL, the same data source.  Now let's
say phone
	1234 and 1235 are registered to server 1 and phone 1236 and 1237
are
	registered to server 2, 1234 can call 1235 and vise versa, 1236
can call
	1237 and vise versa.

	Now from phone 1234 on server 1, I call 1236 on server 2 and
because 1236
	does not have a priority 1 entry on server 1, the call
progresses to a DUNDi
	lookup statement in the diaplan logic and request exten 1236
location from
	the DUNDi peering master server (these registration servers all
are peered
	with the dundi peering master server with a ttl=2, so the
request will get
	past the peering master server and on to the other registration
servers).
	The request is answered from server 2 and 1234 can now complete
a call to
	1236. This is great, all is well, life is good, had a big Dallas
barbeque
	lunch to celebrate because all my sip phones are dynamically
registering to
	any one of 4 sip registration servers, and the other three
servers know who
	is registered where through DUNDi lookups.  And it only took me
2 weeks to
	get this far.

	Now then, let's break it and see what happens, dial any sip
phone that is
	not actively registered and you get an endless DUNDi lookup
request from all
	servers except the one you are dialing from.  I only had one
other server on
	at this time and within seconds produced 590+ IAX trunks
initiated back into
	a registration server before I could hang up the line.

	As far as I can tell, if you make a call from server 1, exten
1234 to exten
	1236, but 1236 is not actively registered on any other server,
the other
	server will get the DUNDi lookup request and not know where the
phone is so
	it keeps looking up and calling itself to find an extension that
is not
	there, or something, anyhow it's a bad thing.

	Now intrinsically knowing that this protocol is smarter than me,
I'm
	guessing that I have incorrect dialplan logic that is allowing
this to
	happen.  I'm wondering how I can set up a dialplan flow that
will do this:

	>From Server 1, pick up phone and dial a number (phone)(exten),
	1. * checks to see if the phone is first registered and on-line
on server 1
	2. if so, dial it, follow standard dialplan login
	3. if not, goto DUNDi switch, lookup where it may be
	(this is pretty much working good)

	On Server 2,
	1. DUNDi lookup request comes in
	2. check to see if extention is active on this server(2), if
not, stop, or
	at least don't continue to look for something within your own
dialplan that
	is not there.

	I'm very open to suggestions.  I feel like I'm so close but also
still far
	away.

	Thanks

	JR

	_______________________________________________
	--Bandwidth and Colocation provided by Easynews.com --

	Asterisk-Users mailing list
	To UNSUBSCRIBE or update options visit:
	   http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060314/44fddde3/attachment.htm