<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>[Asterisk-Users] Clustering "NEW THREAD", Almost Working</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1491" name=GENERATOR></HEAD>
<BODY dir=ltr>
<DIV dir=ltr align=left><FONT face=Tahoma><FONT size=2><SPAN
class=360261015-14032006><FONT face=Arial color=#0000ff>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.</FONT></SPAN></FONT></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Tahoma><FONT size=2><SPAN
class=360261015-14032006></SPAN></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Tahoma><FONT size=2><SPAN
class=360261015-14032006></SPAN></FONT></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Tahoma><FONT size=2><SPAN
class=360261015-14032006> </SPAN><STRONG>From:</STRONG>
asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] <B>On Behalf Of </B>Douglas
Garstang<BR><B>Sent:</B> Tuesday, March 14, 2006 12:11 AM<BR><B>To:</B> Asterisk
Users Mailing List - Non-Commercial Discussion<BR><B>Subject:</B> RE:
[Asterisk-Users] Clustering "NEW THREAD", Almost
Working<BR></FONT></FONT><BR></DIV>
<DIV></DIV>
<DIV>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.</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV><FONT size=2>-----Original Message----- <BR><B>From:</B> JR Richardson
[mailto:jr.richardson@cox.net] <BR><B>Sent:</B> Mon 3/13/2006 7:11 PM
<BR><B>To:</B> asterisk-users@lists.digium.com <BR><B>Cc:</B>
<BR><B>Subject:</B> [Asterisk-Users] Clustering "NEW THREAD", Almost
Working<BR><BR></FONT></DIV>
<P><FONT size=2>All,<BR><BR>I made some progress, but it seems the further I
go with clustering the<BR>harder things get. Hmmm, I guess if it were
easy, it would be<BR>documented......<BR><BR>Anyhow, I have 1 * server as the
DUNDi peering master with a ttl=1. The<BR>only function of this server
is to lookup where other sip peers are<BR>registered and forward that info on
to the requesting * server.<BR><BR>I have 4 * servers accepting registrations
from sip users (phones). All the<BR>sip phone info is stored in a MySQL
database and being accessed through the<BR>realtime engine, and it works
great. A phone registers to a server and the<BR>server checks the
database and if an entry is present, the * servers allows<BR>the phone to
register and dumps the sip phone into sip show peers, works<BR>great. I
can take the sip entry out of the database and the phone will not<BR>resister
in realtime. Works great.<BR><BR>Now the dial plan setup. All the
extension info is also in the MySQL<BR>database, I have a switch statement in
the [siptest] context pointing to the<BR>database for extension logic.
This also works great. All servers are<BR>pointing to the same data
source with all sip extensions in the database<BR>starting with<BR>exten =>
1234,2,Answer and so on<BR>exten => 1235,2,Answer and so on<BR><BR>notice
the priority 2 starting point in the database, very important.<BR><BR>This is
the good part, in sip.conf, I have regcontext=siptest in the
general<BR>section (because it doesn't work in the users section), so when a
sip phone<BR>registers on a server, * dynamically inputs an exten =>
1234,1,Noop into the<BR>dialplan and immediately the phone is able to be
called. This is working<BR>pretty damn well also.<BR><BR>So at this
point I have several phones registered across 4 * servers, all<BR>pulling
their info from MySQL, the same data source. Now let's say phone<BR>1234
and 1235 are registered to server 1 and phone 1236 and 1237 are<BR>registered
to server 2, 1234 can call 1235 and vise versa, 1236 can call<BR>1237 and vise
versa.<BR><BR>Now from phone 1234 on server 1, I call 1236 on server 2 and
because 1236<BR>does not have a priority 1 entry on server 1, the call
progresses to a DUNDi<BR>lookup statement in the diaplan logic and request
exten 1236 location from<BR>the DUNDi peering master server (these
registration servers all are peered<BR>with the dundi peering master server
with a ttl=2, so the request will get<BR>past the peering master server and on
to the other registration servers).<BR>The request is answered from server 2
and 1234 can now complete a call to<BR>1236. This is great, all is well, life
is good, had a big Dallas barbeque<BR>lunch to celebrate because all my sip
phones are dynamically registering to<BR>any one of 4 sip registration
servers, and the other three servers know who<BR>is registered where through
DUNDi lookups. And it only took me 2 weeks to<BR>get this
far.<BR><BR>Now then, let's break it and see what happens, dial any sip phone
that is<BR>not actively registered and you get an endless DUNDi lookup request
from all<BR>servers except the one you are dialing from. I only had one
other server on<BR>at this time and within seconds produced 590+ IAX trunks
initiated back into<BR>a registration server before I could hang up the
line.<BR><BR>As far as I can tell, if you make a call from server 1, exten
1234 to exten<BR>1236, but 1236 is not actively registered on any other
server, the other<BR>server will get the DUNDi lookup request and not know
where the phone is so<BR>it keeps looking up and calling itself to find an
extension that is not<BR>there, or something, anyhow it's a bad
thing.<BR><BR>Now intrinsically knowing that this protocol is smarter than me,
I'm<BR>guessing that I have incorrect dialplan logic that is allowing this
to<BR>happen. I'm wondering how I can set up a dialplan flow that will
do this:<BR><BR>>From Server 1, pick up phone and dial a number
(phone)(exten),<BR>1. * checks to see if the phone is first registered and
on-line on server 1<BR>2. if so, dial it, follow standard dialplan login<BR>3.
if not, goto DUNDi switch, lookup where it may be<BR>(this is pretty much
working good)<BR><BR>On Server 2,<BR>1. DUNDi lookup request comes in<BR>2.
check to see if extention is active on this server(2), if not, stop, or<BR>at
least don't continue to look for something within your own dialplan that<BR>is
not there.<BR><BR>I'm very open to suggestions. I feel like I'm so close
but also still
far<BR>away.<BR><BR>Thanks<BR><BR>JR<BR><BR><BR><BR>_______________________________________________<BR>--Bandwidth
and Colocation provided by Easynews.com --<BR><BR>Asterisk-Users mailing
list<BR>To UNSUBSCRIBE or update options visit:<BR> <A
href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</A><BR></FONT></P></BLOCKQUOTE></BODY></HTML>