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

Mon Feb 21 15:16:18 CET 2005

I'm not sure I follow. When the SIP client hangs up the BYE is
record-routed to SER which then records the BYE. Any downstream or
upstream PSTN gateways would also be record-routed so they would tear
down the call properly.

regards,
Paul

On Mon, 21 Feb 2005 13:51:05 +0000, Iqbal Gandham <iqbal at gigo.co.uk> wrote:
> The fifo part is where i was coming unstuck also, however someone
> mentioned something about fifo_relay which might help, since I need to
> put it on my web cluser as opposed to on SER box. I agree it is good as
> a base especially if you dont have the time to write your own.
> 
> In regards to the billing, this would be fine for postpaid, since we can
> get the mins, and then just do the maths for various destinations etc
> using a rate table, however for postpaid wont you have to disconnect the
> call somewhere, if so how do you (if you do) send the BYE message to the
> gateway once the timer has run out
> 
> Iqbal
> 
> 
> Java Rockx wrote:
> > We do billing from the SER acc module by recording INVITE and BYE
> > messages. We do not worry about accounting at the PSTN gateway. Fraud
> > detection and billing must be handled outside of the scope of the SIP
> > proxy if scaleablity is important.
> >
> > The reason I say this is that the RTP streams have the most impact on
> > systems and we do not believe that a VoIP platform can afford to route
> > all RTP traffic for the sake of accounting at the PSTN gateway.
> >
> > On the serweb note, we concluded that serweb is nothing more than a
> > "good" reference at best. Our decision to scrap serweb in favor of a
> > 100% homegrown interface was based on the fact that serweb is nowhere
> > near optimized for large installations. The way it hits the database
> > repetitively for the same data is crazy. And that smarty stuff is too
> > expensive, IMHO.
> >
> > Our homegrown PHP system fully supports multiple domains, as does our
> > SIP proxy, and we don't have nearly the amount of code to maintain. We
> > have all the functionality of serweb, except for the Instant Messaging
> > because we don't use the Jabber module in ser.
> >
> > Another major problem with serweb, and perhaps this is the most
> > important, is that serweb uses the FIFO in ser, which forces serweb to
> > live on the same box as the sip proxy. This is very very very bad. Our
> > web application has zero ties to the sip proxy, and we fully support
> > Click2Dial, voicemail, etc, etc, and we fully scale just like any good
> > Apache installation.
> >
> > Just my US$0.02 worth.
> >
> > Regards,
> > Paul
> >
> >
> > On Mon, 21 Feb 2005 13:22:38 +0000, Iqbal Gandham <iqbal at gigo.co.uk> wrote:
> >
> >>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
> >>>
> >>>.
> >>>
> >>
> >
> > .
> >
>