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

[Java Rockx]

Guys, 

If I might suggest emailing a ser.cfg to everyone privately so make
sure it is rock solid before sharing with the serusers list.

The reason is that others my immediately use the ser.cfg verbatim and
when blast us with questions. So by having a known "good" ser.cfg on
the mailing list we could mitigate other users questions for problems
that would have otherwise been fixed.

Also, we should come to an agreement of what the overall system should
do - you know, a kind of reference for others to build upon.

My setup uses SER v0.9 and Asterisk-1.0.2. The Asterisk server is used
__ONLY__ for voicemail because - well lets face it, Asterisk sucks as
a SIP router because it just isn't designed to be one.

So all users are managed by SER and Asterisk only comes into play for
voicemail and for playing recordings such as "the party you are
calling has blocked your call" when a call block is enabled.

We should leave redundancy out of the picture for now because fault
tolerant SER is still something many users don't use and it's
something that is still maturing in SER. Besides, my opinion on this
matter is that a "ser clustering" should be a product of the Linux HA
technologies (expect for registration functionality).

The ser.cfg we present should also show how to use MySQL for
accounting, usrloc, etc.

serweb should be avoided altogether because this is nothing more than
a reference implementation that I believe not a primetime offering,
again, just my humble opinion.

Failover PSTN gateways must be covered as well as NAT traversal. The
NAT traversal I use is mediaproxy because it seems to just work
better, especially in distributed deployments.

On this NAT note, my ser.cfg only proxies RTP streams when one or more
SIP clients is behind a NAT firewall. The exception to this is when a
SIP client needs to hit the Asterisk server. The reason for this is
that the Asterisk server is physically a differenet machine that does
not have direct access to the internet. Instead I use the SER server
with two (2) ethernet interfaces, whereby eth0 is the public interface
and eth1 is a 10.0.0.0 private network and I use a crossover cable to
the Asterisk server, which has only one private 10.0.0.0 interface.

Since almost all serusers seem to be interested in voicemail I'd
suggest detail instructions on the Asterisk integration. I use the
ast_data patch, which is kindly provided by bwsys because this makes
managing Asterisk mailboxes a function of the MySQL database. And the
only other real hard part to Asterisk integration is the Message
Waiting Indicator, which I have modifed the app_voicemail.c file in
Asterisk to handing SUBSCRIBE messages a bit differently and I use
sipsak to send NOTIFY messages back to SER, which then proxies the
NOTIFY message to registered SIP clients to turn their MWI on or off.

Call features should also be covered in the ser.cfg. Things like call
blocking, speed dialing, click2dial, etc. Things like 3-way calling,
call waiting, etc should not be covered because they are functions
usually implemented as IAD features.

So basically this is a whole sip proxy, except for the redundancy part.

Our company has a full tcp/ip networking patch that we plan to release
to the ser project. This tcp/ip patch gives us full FIFO functionality
as a TCP socket, and this is something we hope would be commited to
CVS and maintained in the core. As far as we can tell the networking
patch is stable, but we need to prove this further.

So in closing, if anyone things we're better off coming up with a
ser.cfg in private, then let me know. If everyone things that the
serusers list is the place to do this then lets start for the benefit
of everyone!

Regards,
Paul Hazlett
Celebration, FL USA


On Sun, 20 Feb 2005 20:39:14 -0000, Simon Miles <simon at systemsrm.co.uk> wrote:
> As someone who as started from nothing and ended up with a working
> system I would totally agree with Paul.
> 
> If we describe a working scenario, i.e. the IP addresses of gateways,
> Asterisk etc and then describe a ser.cfg then most users will take this
> and learn how to deploy in their scenario.
> 
> I'm happy to pull this together.
> 
> 
> Simon
> 
> -----Original Message-----
> From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> Behalf Of Java Rockx
> Sent: 20 February 2005 13:13
> To: Greger V. Teigre; serusers at lists.iptel.org
> Subject: Re: [Serusers] "Best practice" document,was Warning:
> sl_send_reply: I won't send a reply for ACK!!
> 
> 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
> >
> >
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> 
>