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@ser1.domain.com and UA_B will be registered as UAC_B@ser2.domain.com. UAC_A will be able to call UA_B as "B" or as "B@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@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