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

[Iqbal Gandham]

I would disagree with serweb, I think its very googd, especially the 
newer version which implements domain based system, hence if you are 
supporting several virtual sip providers it provides a good base 
platform on which to add things/features.

You mentioned that you only use the mediaproxy when one or both are 
behind NAT, if this is the case (and a good one :-)), then how do you 
handel the billing or is that done at the gateway i.e cisco , since if 
the media stream is not passing through, then its a bit hard to control 
the call...which is why I originally went with asterisk, and passed the 
calls through there, but am now moving more towards your suggestion of 
using asterisk just for the conf calling/voicemail type of things. 
Although its did have a nice rate engine built in :-)

Iqbal

Java Rockx wrote:
> 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
>>
>>
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> .
>