SIP wrote:
things. SER and SEMS combined, on the other hand, while fast, powerful, and a fully-featured SIP proxy/Media server combination, has sparse documentation, is absolutely painful to deploy, and has only the very basic few modules along with it, requiring that, for many features, you write the module yourself.
While I would FAR prefer the core SER coders to continue their work on making SER the stable, fast product it is, and in piecing together all the SIP RFC weirdness into an actual product, SER/SEMS could not go wrong by recruiting some more people to write modules, by making the install create basic configs that work out of the box, and by having detailed and clean documentation. I'd offer my services, but my C/C++
I fully agree. so far though we have received no single application module contribution for SEMS apart from juha's announcement from DB, and with one other exception practically not any line of documentation contributed. obviously not good management from our/my side, as from some discussions on semsdev you can see that people are implementing their apps with SEMS (with, I'd like to add, not the worst support). so, any good advice on how to make that better?
S.