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:[EMAIL PROTECTED] 
        Sent: Mon 3/13/2006 7:11 PM 
        To: [email protected] 
        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
        

<<winmail.dat>>

_______________________________________________
--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

Reply via email to