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

[Java Rockx]

Steve,

I fully agree - and this is the exact reason that this cannot be a
single person endeavor.

Regards,
Paul


On Mon, 21 Feb 2005 07:28:02 -0500, Steve Blair <blairs at isc.upenn.edu> wrote:
> 
> Greger V. Teigre wrote:
> 
> > Paul, I fully support the approach: Make one reference design with a
> > complete ser.cfg.  This will give us a Getting Started.  We can later
> > add sections on the more advanced stuff like redundancy, radius, etc.
> > Thanks for your review of the components in such a reference design
> > (I'll relate to those further below).
> >
> >    I believe there are two hurdles to get on top of ser: Get a first
> > working config up and running and then understanding the concepts good
> > enough to start tweaking.  Many will not have all the components of
> > the full reference system you describe, Paul, so a starting point with
> > a minimum system is probably needed.  I.e. Get a UA registered without
> > auth, etc (I see some questions on this too)
> >
> I'd like to add a third hurdle, keeping this or any documentation
> up-to-date. One of the biggest issues
> I've faced is keeping a working, production supporting, configuration
> "correct" across release changes.
> The situation doesn't get better if there is alot of out dated
> documentation.
> 
> In addition to a few core examples I'd suggest a clearly worded
> changelog. The changelog needs to
> be clearly show what has changed and what is impacted by the change on a
> release by release basis.
> 
> $0.02
> 
> >    I thus see the following things that must be addressed:
> > - How to read the basic ser.cfg
> > - The basic ser.cfg, what does it do, what is the reference design (is
> > the ser.cfg in cvs appropriate?)
> > - A description of the reference design with a "component list"
> > - The complete ser.cfg
> > - Conceptual explanations of each logical part of the ser.cfg
> > - External systems (Asterisk, mediaproxy/nathelper), configs, etc
> >
> > See my inline comments with regards to a reference design.
> >
> >> 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 also use 0.9, but does not yet support voicemail.  I think we
> > should concentrate on 0.9 capabilities and forget about 0.8.14.  Most
> > people starting up now will probably use 0.9, at least shortly when it
> > is released as stable.
> >
> >    Voicemail adds a layer of complexity in terms of scalability and
> > redundancy.  IMHO we should leave out voicemail from the reference
> > design, not because it is something most people would not want, but
> > because it introduces an external component and complexity that is
> > better added later in the document (like redundancy). That being said,
> > I think we should include voicemail and voiceprompts as part of the
> > initial work on this document, just not leave it as the main reference
> > design.
> >    Sems is a bit less complex than Asterisk and uses the same style
> > config, could it be an alternativ in the reference design?
> >
> >> 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).
> >
> >
> > Yes, I agree that we should leave redundancy out. Using Linux HA does
> > not necessary make it simpler...  Also, in order to get network
> > redundancy when you have distributed users, you need geographic
> > distribution of ser servers. But, again, the complex stuff should be
> > left until later.
> >
> >> The ser.cfg we present should also show how to use MySQL for
> >> accounting, usrloc, etc.
> >
> >
> > Agree. We use RADIUS-based authentication and authorization with
> > distributed RADIUS servers. Only usrloc is stored in mysql (we use
> > avp_radius_load), but we do accounting to mysql.  I can maybe
> > volunteer to do a RADIUS-section later, covering auth, uri, avps etc,
> > but we should concentre on the basics first.
> >
> >> 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.
> >
> >
> > Agree. But, maybe somebody will volunteer to add an add-on section on
> > serweb?
> >
> >> 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.
> >
> >
> > NAT Traversal, I agree. Failover PSTN GW is a more advanced option.
> > Especially if that means introducing the new lcr module from cvs head.
> > :-)
> >
> >> 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.
> >
> >
> > We use rtpproxy where ser is located on one server and the rtpproxy on
> > another.  They communicate across udp (inside an ipsec tunnel). I.e.
> > they are geographically distributed to keep the rtpproxy server as
> > close as possible to the subscribers.
> >    Our UAs are configured with STUN and the RTP streams are only run
> > through our proxy server if an UA is behind a symmetric NAT and gets
> > an incoming conversation (or both are behind symmetric NAT).
> >    Calls where both UAs are behind the same NAT will always be forced
> > through the rtpproxy (to avoid hairpin problem).
> >
> >> 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.
> >
> >
> > IMHO, this is not a basic reference design, but rather advanced...
> > ;-)  Of course, there are many people who would love to see this
> > design described.
> >
> >> 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.
> >
> >
> > Agree.
> >
> >> 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.
> >
> >
> > Good news! You have probably seen Andreas' effort in this same
> > direction using XMLRPC. I guess you have patched the core like Juha
> > suggested in the XMLRPC dialogue? This is an area where a lot of
> > parallel work can be avoided.
> >
> >> 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!
> >
> >
> > If you start out by making an initial draft by dumping in you config
> > and making some headers, you can send it to us for adding content.  If
> > you submit it on the list with a call to submit suggestions and
> > wishes, we can either rotate the document edit privilege or work on
> > different parts of it?!
> >
> > Best regards,
> > g-) aka
> > Greger V. Teigre
> > AxxessAnywhere, Oslo, Norway
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> 
> --
> 
> ISC Network Engineering
> The University of Pennsylvania
> 3401 Walnut Street, Suite 221A
> Philadelphia, PA 19104
> 
> voice: 215-573-8396
> 
>        215-746-8001
> 
> fax: 215-898-9348
> 
> sip:blairs at upenn.edu
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>