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

Java Rockx javarockx at gmail.com
Mon Feb 21 13:39:19 CET 2005


Dial plans must be covered. This is a basic requirement for nearly all
SER implementations.

Regards,
Paul


On Mon, 21 Feb 2005 09:44:43 -0000, Chris <ser at cannes.f9.co.uk> wrote:
> Do you propose different dial plans
> e.g. EU vs US vs ... ?
> 
> -----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
> 
> --
> 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
> 
>




More information about the sr-users mailing list