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

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(a)gigo.co.uk>

> 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(a)gigo.co.uk>

>> >> >>>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(a)gigo.co.uk>

>>>> >>>> >>>> >>>>>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

>>>>>the call...which is why I originally went with asterisk, and passed

>>>>>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

>>>>>>SER implementations. >>>>>> >>>>>>Regards, >>>>>>Paul >>>>>> >>>>>> >>>>>>On Mon, 21 Feb 2005 09:44:43 -0000, Chris <ser(a)cannes.f9.co.uk>

>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>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]

>>>>>>>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:

>>>>>>>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

>>>>>>>when blast us with questions. So by having a known "good" ser.cfg on >>>>>>>the mailing list we could mitigate other users questions for

>>>>>>>that would have otherwise been fixed. >>>>>>> >>>>>>>Also, we should come to an agreement of what the overall system

>>>>>>>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

>>>>>>>__ONLY__ for voicemail because - well lets face it, Asterisk sucks

>>>>>>>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

>>>>>>>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

>>>>>>>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

>>>>>>>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

>>>>>>>SIP clients is behind a NAT firewall. The exception to this is when

>>>>>>>SIP client needs to hit the Asterisk server. The reason for this is >>>>>>>that the Asterisk server is physically a differenet machine that

>>>>>>>not have direct access to the internet. Instead I use the SER server >>>>>>>with two (2) ethernet interfaces, whereby eth0 is the public

>>>>>>>and eth1 is a 10.0.0.0 private network and I use a crossover cable

>>>>>>>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

>>>>>>>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

>>>>>>> >>>>>>>Call features should also be covered in the ser.cfg. Things like

>>>>>>>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

>>>>>>> >>>>>>>Our company has a full tcp/ip networking patch that we plan to

>>>>>>>to the ser project. This tcp/ip patch gives us full FIFO

>>>>>>>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

>>>>>>>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:

.