[Serdev] usrloc loading

Tue Jan 23 09:17:32 UTC 2007

My turnaround time is probably too fast for Jiri, here... Only about a 
week :-) So, Jiri, feel free to jump in whenever you have the time!

Martin Hoffmann 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.
>   
Yes, I totally agree. That's why one of my dearest projects is creating 
best practice scenarios and corresponding configs that actually work and 
do follow the standards. It is much easier to adapt a good ser.cfg than 
to build an RFC-compliant one from scratch.
>> 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".
>   
Yes, you're right. It sounds sort of arrogant. ;-)

I think the discussion we should have (and it's long overdue) is "who 
should SER be for?"

And I think we should argue why, put it on iptel.org (call it why/why 
not SER?) and then people will be able to evaluate whether SER is the 
right thing for them.
My suspicion is that SER is different things for different people, so 
this might be a tricky discussion. However, unless we have the 
discussion (and assuming we want a community of some sorts), wrong 
people will enter the community, push things in the wrong direction, get 
frustrated, frustrate others, and then leave saying bad things.
> 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)".
>   
:-) In fact, to me, OpenSER seems to pretend that it is all things to 
all people. That may work for a while (and in fact, maybe we should send 
some people to OpenSER...) IMHO, it seems that OpenSER is going in the 
opposite direction of SER by introducing all sorts of "special case" 
functionality that confuses people and allows them to break more parts 
of the RFCs.
>   
>> 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.
>
>   
Well, here you describe exactly such a best-practice scenario for more 
than one server, which I would like to have documented... So I think we 
are on the same page.
> 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.
>   
Well, using your own argument with regards to usrloc-cl: they should 
still have the tools and flexibility available in SER, so they don't 
have to rewrite SER to accomplish what they want.
And unless we describe the various scenarios we want SER to support, we 
don't know whether they are really needed or really work. So again, we 
are on the same page here.
>> 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.
>   
Unless that's how you do it in a production environment, it's sort of a 
theoretical suggestion, isn't it?! ;-)

My point was not XMLRPC, but rather trying to define som basic 
mechanisms that we need in SER so that the sysadmins have the tools 
available to implement their preferred failover/load balancing 
solution.  My attempt was not good enough, so maybe you could give a 
shot at it?  (You have at least supported usrloc-cl, which is one of 
these "tools" needed for some scenarios.)
g-)
> Regards,
> Martin
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070123/0abdb734/attachment.htm