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

[Steve Blair]

Chris wrote:

>Do you propose different dial plans
>e.g. EU vs US vs ... ?
>  
>
  You correctly point out the problem with one all encompassing 
configuration.
I think it would be better to have illustrated examples of core 
functions and leave
the site specific tailoring of the config file to each site.

again $0.02

>-----Original Message-----
>From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
>Behalf Of Java Rockx
>Sent: 21 February 2005 01:05
>To: Simon Miles
>Cc: serusers at lists.iptel.org
>Subject: Re: [Serusers] "Best practice" document,was Warning: sl_send_reply:
>I won't send a reply for ACK!!
>
>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
>
>
>
>
>  
>

-- 
  
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