What I would like to do is have two identical *
servers which accept registrations of sip extensions
4000-4999.
If I define a rrDNS or LinuxHA then I should have
load-balanced registrations.
However, say ext. 4001 is registered on *1 and 4002 is
registered on *2, if 4001 tries to call 4002 then I
would like to do something like:
- lookup 4002 on *1, try to establish a call if it's
REGISTERED here
- if it's not registered here then try to look it up
on *2 and establish the call there
I tried to use DUNDi on my local servers but I can't
seem to make it work. Most howtos out there explain
the use of DUNDi when the extension ranges do not
overlap.
So in my case where both *1 and *2 have the same local
extension range 4XXX, can I go the DUNDi route or
should I stop bashing my head on that and explore
another solution?
If someone has configured a similar system then I'd
greatly appreciate some tips.
I read a few dundi docs like
http://www.voip-info.org/wiki-DUNDi.
Thanks
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
On Fri, Feb 22, 2008 at 11:42 AM, Vieri <rentorbuy at yahoo.com> wrote:> However, say ext. 4001 is registered on *1 and 4002 is > registered on *2, if 4001 tries to call 4002 then I > would like to do something like: > - lookup 4002 on *1, try to establish a call if it's > REGISTERED here > - if it's not registered here then try to look it up > on *2 and establish the call thereYou can do that using the dial plan. - Create an IAX link between both servers - DIal plan in both servers: First priority Dial using SIP/EXTEN Second priority IAX/EXTEN Dial IAX/EXTEN -- Andres Jimenez GPG : http://www.andresin.com/gpg/gandresin at gmail.com.asc
Yehavi Bourvine +972-8-9489444
2008-Feb-22 17:44 UTC
[asterisk-users] load balancing SIP extensions
> What I would like to do is have two identical * > servers which accept registrations of sip extensions > 4000-4999. > > If I define a rrDNS or LinuxHA then I should have > load-balanced registrations. > > However, say ext. 4001 is registered on *1 and 4002 is > registered on *2, if 4001 tries to call 4002 then I > would like to do something like: > - lookup 4002 on *1, try to establish a call if it's > REGISTERED here > - if it's not registered here then try to look it up > on *2 and establish the call there >...I've tried doing something similar and came with two options. The common to them is that I use MySQL for realtime extensions, and set "systemname" parameter to the IP address of the server where the phone registers. When a call arrives I check whether the REGSERVER coloumn is the same as the local server or not. If not, then there are two options: - Pass the call via IAX to the other servers; this makes both server process the call and the audio. - Send a "refer" message to the caller to contact the other server. I had this working in the lab but not in production yet. If you want the dialplan code for this then email me. __Yehavi:
> > I tried to use DUNDi on my local servers but I can't > seem to make it work. Most howtos out there explain > the use of DUNDi when the extension ranges do not > overlap. >The following doc describes using the same extensions across multiple * servers. It requires using realtime, but seems to do what you describe. http://www.astricon.net/files/usa06/Friday-General_Conference/JR_Richardson_Whitepaper.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080222/a824f288/attachment.htm
Vieri wrote:> What I would like to do is have two identical * > servers which accept registrations of sip extensions > 4000-4999. > > If I define a rrDNS or LinuxHA then I should have > load-balanced registrations. > > However, say ext. 4001 is registered on *1 and 4002 is > registered on *2, if 4001 tries to call 4002 then I > would like to do something like: > - lookup 4002 on *1, try to establish a call if it's > REGISTERED here > - if it's not registered here then try to look it up > on *2 and establish the call there > > I tried to use DUNDi on my local servers but I can't > seem to make it work. Most howtos out there explain > the use of DUNDi when the extension ranges do not > overlap. > So in my case where both *1 and *2 have the same local > extension range 4XXX, can I go the DUNDi route or > should I stop bashing my head on that and explore > another solution? > > If someone has configured a similar system then I'd > greatly appreciate some tips. > I read a few dundi docs like > http://www.voip-info.org/wiki-DUNDi. > > Thanks > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >Have you tried placing the sip registrations in a db using realtime?
On Fri, 22 Feb 2008 19:44 +0200, Yehavi Bourvine +972-8-9489444 < YEHAVI at vms.huji.ac.il> wrote:> When a call arrives I check whether the REGSERVER coloumn is the same as > the > local server or not. If not, then there are two options: > > - Pass the call via IAX to the other servers; this makes both server > process > the call and the audio. > > - Send a "refer" message to the caller to contact the other server. >You may actually want to use a "redirect" message for this (e.g SIP 302 response). In any case, traversing only one server in the signaling/media path as opposed to two would generally seem more efficient. -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080223/31a96167/attachment.htm