Pietro Ravasio writes: what happens if ser_1 or ser_2 is down when this call takes place? i don't at all like an idea of mixing a third component (asterisk) to this. the whole thing should be doable with sers and load balancers alone. -- juha

I agree with Juha: Mixing Asterisk into this is not something I will want to do. The whole point of load balancing SER is to increase redundancy and scalability. Adding Asterisk to the mix will increase the costs too much. doing authentication in asterisk is also something I would not want to do, it should be handled by ser. I think that the dispatcher module of ser can be used cheaper instead of using LVS, which will not give you call-id persistance anyway. AFAIU, your scenario is quite similar to what I described in this thread: http://lists.iptel.org/pipermail/serusers/2005-May/019118.html Just a different implementation... I'm not sure I understand how you would store the locations. By manipulating the registered contact? Especially: What does this imply in terms of ser.cfg config or possibly ser code change? If it's work, it's a workaround. No better or worse than other workarounds... g-) Pietro Ravasio wrote: > Hi all, > > I've read different approaches towards load balancing, expecially in > these two threads: > http://lists.iptel.org/pipermail/serusers/2005-May/019107.html > http://lists.iptel.org/pipermail/serusers/2005-April/018058.html > > Unfortunately it seems that at the moment there's not a "state of the > art" solution, so here is my "two cent" idea. > > Project goal: to develop a near-linearly scalable platform with NAT > traversal support and call control. > > Proposed solution: multiple instances of SER will be reacheable via an > unique virtual IP handled by LVS (with udp persistence), all SERs > will use the same MySQL backend, an array of Asterisk servers will > act as SBCs (Session Border Controller). > > Every SER will have a "third level" SIP domain associated to it, for > instance UA_A will be registered as UA_A(a)ser1.domain.com and UA_B > will be registered as UAC_B(a)ser2.domain.com. UAC_A will be able to > call UA_B as "B" or as "B(a)domain.com".com"; SRV records for "domain.com" > will be LVS virtual IP, SRV records for third level domain will be > internal, not visible to Uas and associated to IP addresses:ports of > every SER instance. > > > ## Without call control, there would be only one call leg: > When UA_A calls UA_B, its INVITE will reach the same SER it has > previously registered to (SER_1, thanks to LVS persistence), SER_1 > will then look for UA_B and will notice that it is registered as > UA_B(a)ser2.domain.com, DNS will be queried and SER_2 will be contacted > in order to handle INVITE and send it to UA_B through already opened > UDP channel (resolving NAT). > > ## Instead, we want to be able to control the call process and to > handle RTP nat too, so let's use Asterisk: > -First Leg (left): UA_A calls UA_B, INVITE reaches SER_1 (LVS > persistence), SER_1 finds out that UA_B is @ domain ser2.domain.com > but its dialplan tells him to send the INVITE to one of the Asterisk > servers (one of them). SER modifies the INVITE sent to * with > Contact: (ip:port) of SER_2. -Second Leg (right): Asterisk (after > obtaining authorization and call duration from AAA server) will look > for UA_B at SER_2 and send the INVITE to SER_2 with SDP modified for > the RTP, SER_2 will then forward INVITE (solving NAT problems) to > UA_B ip:port (parameters taken from memory or DB). > > This kind of platform would permit call forking too: if UA_B were > registered through two different proxies SER_1 would fork the call to > two different "call instances" of Asterisk(s). > > Note that we want Asterisk to mangle SDP only when both UA_A and UA_B > have private IP addresses > > > Thanks and kind regards! > Pietro Ravasio