[Asterisk-Users] Hypothetical : Working across multiple servers??

[John Todd]

>Hypothetical question..
>
>Lets say there is a situation where you are using the highest 
>compression codecs for all extensions (I guess that would be G.729) 
>and the load on a single server is overpowering the most powerful 
>single processor(lets say SMP is not an option).. So two or more 
>servers are required..
>
>Or
>
>The situation is that you need fault tolerance so want to have two 
>Asterisk servers serving the same population of users and all users 
>are able to authenticate to both servers (I guess you simply copy 
>the same sip.conf to both servers for this) but you also want all 
>other extensions to be availible to all users irrespective of which 
>server they have connected to..
>
>I guess in a way it would be like an Asterisk cluster of some sort..
>
>What would the solution be? Has anyone got an install similar that 
>they would like to share how it was done?
>
>Later..

There are ugly hacks to get that working currently.  They involve 
using the "busy" +101 priority leaping to do really horrible, 
horrible things.  Failover or distributed load is not handled well by 
Asterisk at the application layer; best to handle it at the IP layer, 
and use a load-sharing device of some sort, and config each server 
exactly the same.

[daydreaming below]

I agree that there is currently lacking in Asterisk the support to 
handle "dynamic" extensions that appear and disappear based on 
registration functions.  This seems to be an unusual holdover from 
old telephony concepts where an extension is "attached" to one 
particular switch, and can't move between switches.  In our case, 
SIP/MGCP/H323/etc. clients are "attached" to certain Asterisk 
servers, and the dial plans to handle each of those extensions needs 
to be explicitly stated.  Bleh.

To do this "correctly" would require significant re-programming of 
the current dialplan to allow dynamic lists of extensions which were 
somehow associated with particular SIP/IAX/H323/etc. users.  Then, it 
would be a simple matter of using the "switch" statement to reference 
the contexts on the remote server.

Note that there would optimally be support for multiple references to 
the same number, such that multi-path ringing would happen.  This 
would allow for "closest answer" type calling (similar to they way 
that some BGP routes are announced from multiple locations - the 
"closest" announcement wins.)

Other problems: I am uncertain if the switch statement dynamically 
updates extension lists on remote servers.  In other words, if after 
you start up two Asterisk servers, and someone were to register 
themselves with a SIP client, is there any mechanism by which the 
remote servers would be able to know about the "new" number if a such 
a plan were implemented?

The example below are preliminary thoughts, but the more I think 
about it, the more I like this idea.  It's very flexible, supports 
multiple dialing authority realms with 'virtual' groups, and even may 
be totally generic across channel types if the standard string 
manipulation tricks were to be implemented in the search.

A user could register with server1 OR with server2, and they would 
get the call.  Each server would be configured almost identically 
(except for the "switch" line, and relevant settings in iax.conf for 
the other peer, which I do not include for brevity.)  In fact, the 
sip user could register with BOTH server1 and server2, and still get 
the call.  (No, this double-registry ability isn't a bug - this is a 
useful feature.  If you want to do account locking, that's a totally 
different story that should not be addressed in these parts of the 
dialplan.)


It might look something like this on each server:

; -------------------------
; extensions.conf snippet
;
[from-my-sip-phones]
include => all-sip
switch  => IAX2/server1:pennypriddy at server2/all-sip
;
exten => i,1,Answer
exten => i,2,Playback(user-not-logged-into-any-servers-now)
exten => i,3,Hangup
exten => h,1,Hangup
;
;
; The extension value ${company1-sip} is really an array of
;  values that represents any static hosts or
;  currently registered dynamic hosts within that
;  particular dynamicgroup name, as filled by the various
;  channel configuration files.
;  If user 2000  were currently registered, then ${company1-sip}
;  would  be expanded, a match would be found, and the
;  SIP call would be completed.
;
; Note that if the extension did not exist in the list, then
;  the call would never be passed in here, so there is no
;  need for an "i" extension in this context (it's handled
;  up in the [from-my-sip-phones] context.
;
;
[all-sip]
exten => ${company1-sip},1,Dial(SIP/${EXTEN})
;
;
exten => h,1,Hangup
;

; -------------------------
; sip.conf snippet
;
;
; dynamicname should default to peer name if not specified (shown
;  in this example for clarity, even though set to the default value)
; dynamicname should support any valid string data
;
; dynamicgroup should default to channel type (sip, mgcp, h323, etc.)
;   if not specified (exten => ${sip},1,Dial(SIP/${EXTEN})
; dynamicgroup should support any valid string data
;
; Neither dynamicgroup nor dynamicname are configured if the
;  SIP device was not registered, or had an invalid "qualify"
;  result (if static.)  Static hosts with no qualify= tests
;  would always appear in the array.
;
;
[2000]
type=friend
username=2000
secret=nomatterwhereyougo
host=dynamic
context=from-my-sip-phones
canreinvite=yes
nat=1
dynamicgroup=company1-sip
dynamicname=2000

[2001]
type=friend
username=2001
secret=notmyplanetmonkeyboy
host=dynamic
context=from-my-sip-phones
canreinvite=yes
nat=1
dynamicgroup=company1-sip
dynamicname=2001

; end sip.conf snippet


JT