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

[Java Rockx]

I see now. Sorry.

The short answer is we don't do prepaid. I know this isn't a good
answer, but it's all I've got. :-(

I assume the best way to address this is to do it after the fact as an
advanced feature.

P


On Mon, 21 Feb 2005 15:05:10 +0000, Iqbal Gandham <iqbal at gigo.co.uk> wrote:
>   I'm saying this is okay if the caller/callee hangs up but what happens
> if you are running prepaid, and they run out of credits, how do you a)
> know when they have run out, since you only record INVITES/BYE and b) if
> you do know when, how do you force a tear-down
> 
> Also in you setup (previous posts), your setup is to place the UA
> in such a way so that they all have public IP's, which means sip to sip
> calling on your own network you can avoid the RTP stream which is great,
> 
> but is there anyone else who cannot force a hardware control, and has
> worked out a scalable way of soing sip to sip calling, when they are
> behind NAT, since I dont need to do billing on it, I would much rather
> not take care of the media stream either, and use my mediaproxy to take
> care of more $$ productive calls like those for pstn
> 
> 
> Iqbal
> 
> Java Rockx wrote:
> > 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
> >>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>.
> >>>
> >>
> >
> > .
> >
>