[Serusers] "Best practice" document, was Warning: sl_send_reply: I won't send a reply for ACK!!

[Java Rockx]

Greg,

How do you think it would be best to start a "best practices"
document? My feelings are that to make the most impact a fully
functional ser.cfg for a real world SIP proxy should be the basis
because most folks on serusers are just looking for a quick "how do I"
answer.

I'd like to think that if I just posted my ser.cfg then the ball would
be rolling on this, however, I doubt that would happen for several
reasons:

* I'm not 100% convinced that my ser.cfg is error free.

* I doubt I've done things exactly correct (ie, I'm sure there are
better way to do some things I've done).

* I've got many inline comments, but a much deeper explaination of key
areas of my configuration are needed.

* My ser.cfg is deeply dependent on external factors, such as our
slightly modified version of Asterisk, which we only use for
voicemail. So I don't think just seeing the ser.cfg would answer too
many questions regarding how MWI works without including Asterisk
integration documentation.

Anyhow, that said I believe that an initial "best practices" document
would need to focus on these key areas:

* Basic ser.cfg structure
* Database usage (enabling/using MySQL)
* NAT traversal
* PSTN integration (ie, gateways)
* Asterisk integration for voicemail only (no call routing logic)

I think that this would solve many of the postings that appear on
serusers frequently.

Regards,
Paul

On Sun, 20 Feb 2005 11:46:58 +0100, Greger V. Teigre <greger at teigre.com> wrote:
> Thanks for your initiative, Paul.
> 
> I suggested in a previous post that a simple FAQ list could be created on
> the iptel.org site pointing to posts on mail.iptel.org that addressed
> commonly asked questions.  Seeing the initiative now on TLS, I realize that
> maybe the only way to get something going is to do something, submit it in
> some way, and then people will start to relate to it.
>     Thus, I suggest that you, if you have the capacity to do so, submit a
> starting point for a such a best practice document.  I will promise to
> review and contribute where I can add value.  If people fancy the document,
> it will be in the interest of the core developers to submit their input
> ("priority by relevance").
> 
>     My company has decided to offer to host a "best practice site" (if it is
> of interest to the community) where the document, reference ser.cfgs, as
> well as links to posts, resources, other people's non-cvs modules etc can be
> presented.  I find voip-info.org to be a good resource, but picture a more
> structured and edited approach to complement and provide easy access to
> resources.
>     Ser is an excellent open source software, but IMHO the project has not
> yet matured enough to be taken seriously for large service providers
> (without somebody like us presenting .  Those of us who make a living that
> includes ser should really collaborate to make ser as best as possible and
> (an even more) viable alternative to commercial software.  We can and should
> compete on other things than who can make the ser.cfg work...
> 
>     The core developers are doing an excellent job, and I believe the best
> way we can help them out is to start initiatives and see if they catch on.
> I think it's in everybody's interest to build a large and stable community
> around ser.
>     I see several initiatives now that point in the right direction, as well
> as areas where work is needed:
> - "Best practice" initiative from Paul
> - My initiative suggesting a new website in this post
> - Andreas' work on scalability (discussed recently on this list)
> - The TLS initiative
> - Need for a viable, scalable voicemail implementation
> - Need for a scalability/redundancy reference design including load
> balancing/multiple server centers
> - Need for database support beyond open-source DBs (ODBC/JDBC/LDAP)
> - Need for access to a repository of modules (beyond those in CVS). Can be
> addressed on my suggested website
> - Need for more application level integration/capabilities (SIP Servlets,
> JAIN, etc)
> - and probably many more
> 
> Well, let's start small. There is a  lot of activity and implementations
> that are being done, partially exposed here on serusers/serdev. By exposing
> and coordinating these efforts publicly, people can concentrate on new and
> even more exciting things than just figuring out how to handle NAT...
> g-)
> 
> Java Rockx wrote:
> > Guys,
> >
> > Since I just made very substantial changes to my ser.cfg I'd like to
> > test my full feature set before sharing it. I'm going to put a new
> > post on serusers_at_iptel.org in a day or two seeking comments on
> > establishing a "best practices" document for ser.cfg and in that post
> > I'll attach my ser.cfg which perhaps could be used as a basis for
> > beginning a dialog on this subject.
> >
> > At a minimum I'd like to see a more complete and complex ser.cfg for
> > which other can base their work.
> >
> > The problem with this is that it would require take some feedback from
> > the ser core team to ensure the "best practices" are correct and
> > properly reflect the designers intent. The reason I think this could
> > be a problem is that Andrei, Jiri, Jan, and company are more than busy
> > already.
> >
> > The bottom line is that as great as ser is, coding practices are
> > mostly a mystry to developers seeking to install ser and when you get
> > in to complex functionality such as call forwarding confusion stumps
> > many users.
> >
> > Regards,
> > Paul
> >
> > On Sat, 19 Feb 2005 19:59:31 +0100 (CET), Medve Istvan <imedve at ew.hu>
> > wrote:
> >>> Perhaps I'll post my entire ser.cfg this week for anyone that wants
> >>> it.
> >>
> >> Please send it to me.
> >>
> >> Thanks,
> >> imedve
> >>
> >>
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> 
>