[Serdev] usrloc loading

[Greger V. Teigre]

Jiri Kuthan wrote:
> At 10:17 23/01/2007, Greger V. Teigre wrote:
>   
>> 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!
>>     
>
> Well, thank you all for your patience and interest in my opinion -- I try at least
> a bit from underway :-) 
>
>
>   
>> 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.
>>>>         
>
> I guess I jumped in quite late, but Martin, could you send me a list of such constraints?
>
> Undisputably though the flexibility in SER is a terrible thing and the only thing
> which would be even worse is not to have it :-) We have observed couple of ways to
> deal with complexity.
>
> Having a bunch of mainstream config files (like onsip.cfg or new ser.cfg and hopefuly 
> more in the future) is certainly most useful. 
>
> In many cases what turned out useful to us was to turn scripting into lcr-like database
> processing -- that helped to lower number of degrees of freedom , was thus less error
> prone and scaled better in many cases.
>   
I don't understand what you mean?! Could you elaborate?
> Yet other thing which turned out to be most useful is proper system packaging along
> with installation and ocnfiguration processes. We have done that for our commercial
> products, it was quite laborous but eventually very useful too. (we used debian)
>   
Yes, that is a good point. ser has a long way to go here, but I can 
point out a few on-going efforts that can be of help here:

 * I'm working on an m4 build system that is generic enough to support 
various config files, but strict enough to enforce a basic best practice 
build up of ser.cfg (A raw first version will soon be ready, so testers 
are welcome!!). Along with it is an interactive script that requests 
basic configuration (done once for each server), as well as a 
configuration file where all the parameters can be controlled for more 
advanced users

 * We have a goal of automating build processes on various systems, thus 
making available packages for various distros and architectures

 * Once SER 2.0 is released, we will make available a vmware virtual 
appliance (probably debian based, but input is welcome) with ser, sems, 
serweb, rtpproxy, and mediaproxy pre-installed and compiled for mysql 
and radius. Together with the m4 build system, a working ser server 
should be available in the matter of minutes (+ appliance download)

 * ser, sems, serweb, and rtpproxy will be made available in a combined 
source package
>
>   
>>>> 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?"
>>     
>
> Mostly service providers in my experience. I like to use it too very much indeed.
> I agree that posting some "am I a potential SER user" on the website may be helpful
> to folks for whom SER is not the ideal tool.
>   
My question is: "service providers" because that's where you have been 
pre-occupied, or because you have knowledge of the user community?  With 
close to 5,000 registered users on iptel.org since the re-launch, I 
assume not all of these are service providers. So, who are they?
>> 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.
>>     
>
> I think the most effective step to carry out it to have folks documented their
> scenarios. There are indeed very many of such, some better for some purposes than
> the others; certainly some would benefit of taking the scenarios off-the-shelve.
>
> Really folks -- stand up and ensure your place in ser's hall of fame :-)
> Just publish scenarios you have tried, the community will amplify the
> result back for you.
>
> We can debate the whole solution space which is almost infinitely large, but
> if folks were willing to publish their best-current-practices, it could save the
> mailing list participants a lot of time. (Badly many of those I'm familiar with
> done for our customers fall under NDAs and I'm afraid the same can be said of
> others...)
>   
I cannot agree more! This is a challenge, people, step up, write up your 
scenario!!!
And Jiri: I'm sure you can generalize quite a lot and come up with a 
couple of pretty well described scenarios that you think open-source ser 
should support?!
> Perhaps a couple of notes may be useful for those who like to try to build a new
> clustering scheme (and these are suggestions of my personal opinion and taste
> which may or more likely may not be anyone else's).
> - never trust database. If you can, get finished on the application/SER side and
>   dont let the traffic go to database. If there is some annoyance, better stop
>   at the gate than in backyard. Specifically, I like to keep usrloc isolated.
> - "horizontal partitioning" is good. Then you have all the data you need at the
>   place where you are -- it is fast and fail-safe.
> - multi-tier  clustering with three levels (IP-LB-ing, SIP lb-ing, and the 
>   eventual 'work horses') seems a good (simple and reliable) division-of-work to me.
>   
Good for a start, some design-principles...  Do you take my challenge? ;-)
g-)

> -jiri
>
> --
> Jiri Kuthan            http://iptel.org/~jiri/ 
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070124/df5d0ed4/attachment.html