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

Do you propose different dial plans e.g. EU vs US vs ... ? -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 21 February 2005 01:05 To: Simon Miles Cc: serusers(a)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 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 18/02/2005