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

[Pietro Ravasio]

on Friday, May 13, 2005 11:48 AM Greger V. Teigre wrote:

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

The only reason I've thought to use Asterisk is that I want a "credit
reservation" method to handle call status that lets me stop the call when
the credit is finished. Now this is something I wouldn't have liked to do in
SER since I didn't want to use it statefully. 

> doing authentication in asterisk is also something I would
> not want to do, it should be handled by ser.

Authentication at the moment is planned to be handled by Ser, authorization
and accounting by Asterisk (that is the only element that knows both call
legs)

Anyway, at the moment "mixing Asterisk with SER" is not my major concern,
I'm pretty worried about trying to use a particular outbound proxy for calls
to a NATed UA:

>    I think that the dispatcher module of ser can be used
> cheaper instead of using LVS, which will not give you call-id
> persistence 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...

Yes, I now agree with you in using this approach rather than "multiple
internal domains" one. The only things I'd like to modify are:
- storing location on every message, not only on REGISTER, in case a ser
dies and lvs udp persistence sends the next UA message to another SER (for
instance my Sipura phone sends a bunch of NOTIFY messages in order to keep
NAT open, if a ser dies and if phone is already authenticated, I want to
update "its SER")
- using only one table for every SER storing in a different column the proxy
(taken from dst_ip) who has handled the message. This way I don't have to
preprovision all SER instances in all ser.cfg routing logics. At this point:

.) if I use a B2B user agent in order to handle NAT (for instance asterisk)
- I'd send INVITE to my B2B UA (t_relay_to_udp("b2bua_lvs_virtual_ip")) with
rewritten Contact: field with the IP number of the (outbound) SER UAB has
registered/sent its latest message to (taken from DB)

..) otherwise, in a "pure SER" environment,
- I'd send INVITE directly to the SER proxy which IP:port is taken from DB
with the same logic as above

Using only one location table could be useful in order to create a flexible
routing logic: if the server taken from DB is not online anymore, send
message to another one (randomly chosen), hoping that UAS is not behind nat.
This logic could be inserted in B2BUA dialing plans or in ser.cfg.

> If it's work, it's a workaround. No better or worse than other
> workarounds... g-)

At the moment I start thinking that any technique that tries to bind an
outbound SER for all calls to a set of user agents, is going to be a
workaround... Am I wrong? :-/

-- 
Ing. Pietro Ravasio - pietro.ravasio at abbeynet.it
Enterprise Market Manager
Abbeynet S.p.A. - http://www.abbeynet.it
TEL: +390702109044
GSM: +393282172055
FAX: +390702109055