[OpenSIPS-Users] How to bill SIP session time correctly?

Olle E. Johansson oej at edvina.net
Thu Jul 29 16:49:48 CEST 2010


29 jul 2010 kl. 16.36 skrev Brett Nemeroff:

> 
> On Thu, Jul 29, 2010 at 9:25 AM, Alejandro Recarey <alexrecarey at gmail.com> wrote:
> When using a pure SIP solution like OpenSIPS, and session timers are
> not enough, how do you bill your customers?
> 
> I have done a number of configurations where calls are billed solely on signalling. Before everyone jumps on my back here, I'll give you the same disclaimer I give everyone. Billing records based on proxy records are not authoritative and it's very important you understand the limitations and potential security risks before even considering using billing records from a proxy. For what it's worth, in a practical setting, I get very good results usually.
>  
> I have seen that one solution is to use MediaProxy or RTP proxy to
> proxy the RTP stream and inform OpenSIPS when the RTP stream
> terminates. Won't this have the same scalability problems as Asterisk?
> Is it a robust solution?
> 
> 
> Using mediaproxy + opensips can absolutely provide an authoritative call record as it *knows* how long the RTP lasted, which is what's really important. There will be some correlation required on your behalf to make this work. If I remember correctly, mediaproxy makes a JSON record of each call as it terminates in media_sessions. This record has really fantastic information about the call.
> 
> Mediaproxy scales much better than Asterisk. Keep in mind that Asterisk's scalability really has more to do with the way it was put together and not so much just on the architecture. In other words, it wasn't really built to RTP proxy 100 calls at once. I'm sure there are plenty of you out there that will disagree with me on that; I always end up hearing someone say that they ran 10,000 calls and never noticed a problem :)  Mediaproxy on the other hand I believe had been tested pretty successfully up to  2000 simultaneous calls on a single box. Of course, just like Asterisk, these numbers are *meaningless* without factoring in your application and the specific hardware you are using. As always, you'll need to do your own benchmark, but I feel pretty confident in saying you'll see a *huge* performance improvement using mediaproxy + opensips over asterisk. Of course, you give up a lot of functionality, but you might not be using much of that anyway. 
> 
Talking as an Asterisk developer, I can say that handling 100 calls simultaneously is no problem today. From Asterisk 1.4 we added a very fast RTPproxy-alike briding code that will be used - as you say, if you don't make it not happen. Transcoding, PBX services and other things will reduce the amount of calls. Asterisk is highly multithreaded and I've done over 10.000 channels on a recent HP server without any issues, using the p2p rtp bridge, which is normally what you use if you only want billing. Handling 2000 channels on a recent server should be no issue - it depends on the NIC interface a lot, but that problem affects ALL rtp proxys.

Just pointing out that your thought of Asterisk propably apply to very, very old versions of Asterisk.

And yes, I have tested the 2.000 channels in a lot of different settings, with various boxes and various pieces of test equipment. The 10.000 channels test was between two HP servers and we reached a limit on the GB ethernet interface, not the CPU.

Cheers,
/O


More information about the Users mailing list