[Serusers] More on load balancing: LVS + SRVs, SER + Asterisk

[Greger V. Teigre]

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

> Have you got any suggestion/comment? (expecially regarding:
> - more SERs using the same MySQL backend

I'm not sure I understand how you would store the locations. By manipulating 
the registered contact?
Especially:
> To achieve this, we will need to store a domain for any UA in the
> "location" table, any instance of SER will do this, UAs don't need to
> know anything about "internal" domains. (Is this to be considered an
> "hack"?)

What does this imply in terms of ser.cfg config or possibly ser code change?

> - binding a third level domain at the proxy

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 at ser1.domain.com and UA_B
> will be registered as UAC_B at ser2.domain.com. UAC_A will be able to
> call UA_B as "B" or as "B at domain.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.
>
> To achieve this, we will need to store a domain for any UA in the
> "location" table, any instance of SER will do this, UAs don't need to
> know anything about "internal" domains. (Is this to be considered an
> "hack"?)
>
> ## 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 at 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
>
> Have you got any suggestion/comment? (expecially regarding:
> - more SERs using the same MySQL backend
> - binding a third level domain at the proxy
>
> Thanks and kind regards!
> Pietro Ravasio