[Serdev] usrloc loading

[Martin Hoffmann]

Greger V. Teigre wrote:
>
> * Martin points out the importance of the flexibility of ser.cfg in 
> supporting various network designs and "ways of doing it". This is true, 
> and I fully agree. However, the "valid" or "appropriate" designs to use 
> DO have constraints, both in SER design, available modules, as well as 
> in ser.cfg language itself.

The biggest problem is that you can easily configure SER in such a way,
that it isn't actually a SIP proxy as per The Standard. This may happen
on purpose (nathelper being the obvious example). But some of the
questions on seruser indicate that people "just do stuff" and wonder why
it breakes.

> Thus, the flexibility of ser.cfg that 
> enables professionals to tune SER, is a curse to others, less experienced. 
> Which of course leads me to the original intention of SER - Getting 
> Started configurations: create best practices for the basic tasks.

The way I see it, SER is a SIP proxy for professionals. This may sound
arrogant, but you _really_ have to know what you are doing. You have to
know SIP otherwise you will break things. Your Getting Started is a very
valuable document on covering these things and help people climbing the
steep parts of the learning curves. But even with those documents, the
fact remains that SER is not the right tool for people who just want to
have a SIP proxy for their private or SMB use. For now, there is
Asterisk; repro is a good proper proxy that "just works".

Open source software is in the fortunate position that it doesn't need
to be sold. It can afford to serve a niche. In this light, the SER
community can afford to be honest and tell some people "SER isn't the
right tool for you (and no, OpenSER isn't either)".

> For some time now, I have tried to rally support around establishing 2-3 
> best practice scenario for MORE THAN ONE SER SERVER!  With 200 users, 
> you still want some redundancy, so people  spend lots of time figuring 
> out how to do things.

They very well may waste their time. In most setups, even of commercial
telephony provider, the SIP servers should be way down on the list of
things that need to be done for high availability. SER has reached a
quite reasonable uptime. All you need is a script that watches SER and
restarts it if things go bonkers. Yes, you may not reach Telco numbers
on uptime, but in the Internet they are a dream anyways (and even Telcos
only reach them by cheating).

What you should have is a standby box where you replicate your database
to and keep an up-to-date copy of your SER config. Then you are ready
for hardware failures and can switch within minutes. For extra credit,
you can implement automatic fail-over to the standby box using VRRP or
somesuch thing.

If you reach the point where you need load balancing, chances are
that your responsible sysadmin has very strong opinions on how to do these
things. Sysadmins tend to be like this, they rather implement their own
solution based on experience.

> Basic idea: Turn up side down on the idea of all servers needing access 
> to all usrlocs and rather implement a discovery system for which server 
> has the registration.
[...]
> * The function will contact each peer according to priority using the 
> standard usrloc lookup command in usrloc module (over XMLRPC). If the 
> contact was found with a peer, either a 30x redirect is sent or the dst 
> ip is changed to the peer and the message is t_relayed

Wouldn't it be simpler to just fork the call to each other proxy? I
mean, that is how SIP is supposed to work. Having XMLRPC on the side
makes debugging more complicated and may introduce an extra point of
failure.

Regards,
Martin