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? :-/