I need implement a prepaid system in my kamilio !
anybody help me !?
any information !
Atenciosamente, Igor Marques
celular: 55 21 7858 7499 nextel: 87*24074 e-mail: igor@carneiro.cc web: www.carneiro.cc
2008/12/23 igor igor@carneiro.cc:
I need implement a prepaid system in my kamilio !
anybody help me !?
How much money are we speaking about?
El Martes, 23 de Diciembre de 2008 13:03, Iñaki Baz Castillo escribió:
2008/12/23 igor igor@carneiro.cc:
I need implement a prepaid system in my kamilio !
anybody help me !?
How much money are we speaking about?
Money, Money, Money .. .allways asking for money ... why do you need it? ... I'll give you blessing forever and you should be happy ... ;-)
I Just installed an Asterisk2billing in an asterisk. I still use openser to load balance to some asterisk2billing(s) It is simple and work fine! Try it. It is a GPL license
http://asterisk2billing.com I wanted to use cdrtool but don't work exactly as I wanted...
Cordialement, BERGANZ François
http://www.acropolistelecom.net Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.
-----Message d'origine----- De : users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] De la part de Raúl Alexis Betancor Santana Envoyé : mardi 23 décembre 2008 14:37 À : users@lists.kamailio.org Objet : Re: [Kamailio-Users] prepaid system
El Martes, 23 de Diciembre de 2008 13:03, Iñaki Baz Castillo escribió:
2008/12/23 igor igor@carneiro.cc:
I need implement a prepaid system in my kamilio !
anybody help me !?
How much money are we speaking about?
Money, Money, Money .. .allways asking for money ... why do you need it? ... I'll give you blessing forever and you should be happy ... ;-)
_______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
BERGANZ François wrote:
I Just installed an Asterisk2billing in an asterisk. [...] It is simple and work fine!
Until you have serious logic and scaling requirements.
On 12/23/08 16:30, Alex Balashov wrote:
BERGANZ François wrote:
I Just installed an Asterisk2billing in an asterisk.
[...]
It is simple and work fine!
Until you have serious logic and scaling requirements.
This is always the case when someone tries to push an application beyond its purpose. It may work, but not as expected - using a pbx-designed system for carrier grade traffic will end up in scaling issues. Probably if one tries to tailor asterisk and remove the parts not required, will increase the performances, but still, it is a pbx concept behind...
Happy holidays! Daniel
Agreed wholeheartedy.
Asterisk is utterly inappropriate for this, as the single underlying engine anyhow.
On Dec 28, 2008, at 4:31 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/23/08 16:30, Alex Balashov wrote:
BERGANZ François wrote:
I Just installed an Asterisk2billing in an asterisk.
[...]
It is simple and work fine!
Until you have serious logic and scaling requirements.
This is always the case when someone tries to push an application beyond its purpose. It may work, but not as expected - using a pbx- designed system for carrier grade traffic will end up in scaling issues. Probably if one tries to tailor asterisk and remove the parts not required, will increase the performances, but still, it is a pbx concept behind...
Happy holidays! Daniel
-- Daniel-Constantin Mierla http://www.asipto.com
On 12/28/08 11:50, Alex Balashov wrote:
Agreed wholeheartedy.
Asterisk is utterly inappropriate for this, as the single underlying engine anyhow.
maybe not that spread as Asterisk, but SEMS has an extension for prepaid. Last meetings with sems developers revealed to me lot of improvements there. Being sip-focused application, sems might be a good point to start building b2bua-based applications.
Also, freeswitch is another application, still considered young by others, but for simple b2bua that I used on it, is just fine.
Happy holidays! Daniel
On Dec 28, 2008, at 4:31 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/23/08 16:30, Alex Balashov wrote:
BERGANZ François wrote:
I Just installed an Asterisk2billing in an asterisk.
[...]
It is simple and work fine!
Until you have serious logic and scaling requirements.
This is always the case when someone tries to push an application beyond its purpose. It may work, but not as expected - using a pbx- designed system for carrier grade traffic will end up in scaling issues. Probably if one tries to tailor asterisk and remove the parts not required, will increase the performances, but still, it is a pbx concept behind...
Happy holidays! Daniel
-- Daniel-Constantin Mierla http://www.asipto.com
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
On 12/23/08 12:21, igor wrote:
I need implement a prepaid system in my kamilio !
anybody help me !?
any information !
I am using kamailio for call routing and scaling. For prepaid and advanced media/call processing I am using FreeSWITCH, Asterisk or SEMS - depends of the needed feature.
In this particular case, i use freeswitch to terminate the call. kamailio and freeswitch integration is seamless, just direct the sip traffic there. However, you need a bit of programming skills to get prepaid functionality (practically you need a back to back user agent).
Happy holidays! Daniel
Hello All!
2008/12/23, igor igor@carneiro.cc:
I need implement a prepaid system in my kamilio !
anybody help me !?
any information !
I also share some bits about our architecture, we currently use at ipport.net.
We using OpenSER (1.3.x) as SIP-proxy and registrar. Every information about users (their accounting data, such as currently established calls, and authorization data) stored in Oracle.
* User authorizes via radius (freeradius with oracle module).
* At the time of user calls somewhere, we (after checking its auth data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
=================
subst_pvar (m, fU, "$fU"); subst_pvar (m, tU, "$tU"); subst_pvar (m, fd, "$fd"); subst_pvar (m, td, "$td");
sqlo_prepare(handle, stmt);
bind_necessary_variables();
if((sqlo_execute(sth, 1) != SQLO_SUCCESS){ LM_ERR("execute FAILED\n"); return -1; }
sprintf (request_uri, "sip:%s@%s", tU, td); a.type = SET_URI_T; a.elem[0].type = STRING_ST; a.elem[0].u.string = request_uri; a.next = NULL;
if (do_action (&a, m) < 0){ LM_ERR("do_action FAILED\n"); return -1; }
=================
If user runs out of money/limit of simultaneous calls/requests for disabled feature we'll forward him to predefined SEMS address with proper message describing current sutiation "sorry, you have no money", "you didn't pay for talk with girls", "you didn't vote for Obama, so we disconnecting you!".
* In order to control rtp between clients (and therefore disconnect them in case of network failure) we using Cisco 28xx routers ( http://www.cisco.com/en/US/products/ps5854/ ), but we currently moving to our custom solution based on our rtp proxy server, since Cisco can't deliver enough calls processing performance for their price.
* In order to drop calls when user runs out of its credit, we use PL/SQL scripts in Oracle + OpenSER's fifo.
* For some particular tasks we also using Sippy B2BUA as B2BUA solution.
That's all, folks.
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle? When I checked the project looked dead.
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module. Probably combined with the new sqlops module in upcoming 1.5, a lot of similar operations as yours can be coded in the config file pretty easy.
Cheers, Daniel
Hello!
2008/12/29 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle?
Yes. We use it in conjunction with Oracle 10g.
When I checked the project looked dead.
I would say that libsqlora8 is finished :) - it works well and therefore doesn't need to be updated.
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module.
No, we haven't tried yet.
On Tue, Dec 30, 2008 at 9:44 AM, Peter Lemenkov lemenkov@gmail.com wrote:
Hello!
2008/12/29 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle?
Yes. We use it in conjunction with Oracle 10g.
When I checked the project looked dead.
I would say that libsqlora8 is finished :) - it works well and therefore doesn't need to be updated.
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module.
No, we haven't tried yet.
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc). LDAP, Radius, SER groups?
- Callflows
- What IVR to use for user notifications (no credit, etc) and user balance check? Asterisk, SEMS, etc?
- How to enforce call tear down when credit is exhausted? What B2BUA to use?
- How to manage recharges?
Etc, etc.
Regards Luciano
It's a good thought.
My concern is that from an economic perspective, coming up with any grand, unifying schemes or projects to solve these architectural challenges is mostly a pointless waste of time.
While admittedly the prepaid model is proving to be quite a viable inroad in many parts of the world outside of the US and W. Europe (and indeed, much of the interest seems to be there), fundamentally it can only exist to the measure that:
(1) Voice switching, transport and subscriber services are billed by per-minute usage, and voice infrastructure and service delivery systems are monetised this way;
(2) The process of rebilling for usage is a derivative function of the economics of PSTN interconnection and how the PSTN TDM carrier-world business model works (a series of billable events and relatively fixed reservations of capacity) versus the Internet business model (primarily flat-rate peering and settlement-free peering among backbone haulers) that revolves around higher-order applications delivered over packets;
(3) There are not too many flat-rate alternatives available elsewhere in the telecom world.
I think #3 is the most important and the one that is likely to prove most relevant in the short term, as I think we can all agree that there is no expectation that the PSTN in a time frame anyone would deem short to immediate term.
For example, here in the US, pre-paid calling cards are largely obsolete and highly irrelevant from a mass-market perspective. They survive in various niches where people remain that are somehow sentimentally or inertially attached to calling cards and fixed-line long-distance; this includes retirees, large communities of first-generation immigrants for whom this is a viable means of making calls to their home countries relatively inexpensively, and so on. But really, by and large landline revenue is falling precipitously, everyone has a mobile, international rate plans are available for those who truly need to make a lot of international calls, and domestic long-distance is increasingly flat-rate / unlimited on fixed-line (and is already so on mobile).
For the most part, people ordering origination (DIDs) in the form of wholesale trunking are interested in flat-rate DIDs as well. Termination will remain usage-based, but only so far as points #1 and #2 above are highly operative, and only so long as private VoIP peering doesn't gain any serious traction.
All these details can be debated at great length, but the salient point here is that this is a business model that is intimately bound up with the idiosyncrasies of the PSTN and the way the incumbent voice business has functioned for almost a century.
It is fairly obvious, I think, that whenever it is that we do get around to moving beyond the PSTN, in part or in whole, the centrality and unassailable importance of "minutes" as a billing fixture will be expected to disappear in line with the ontology to which all other Internet-based application services are subject. Meanwhile, the incumbent telco world will go increasingly to flat-rate and unlimited plans and there will be continuing downward cost pressure, as well as increasing local loop deregulation and unbundling in a variety of other national markets in which state incumbents persist with varying degrees of success.
So, while this sort of stuff can probably make a decent amount of money in the US and Europe if appropriatedly positioned/marketed/specialised, and certainly can work in Latin America, the Middle East, etc., it does have the quality of being somewhat regressive and not particularly forward-thinking. It is overly connected to a shifting and unstable landscape of arbitrage opportunities arising from the position of VoIP relative to the PSTN and wireless; specifically, that most calls still terminate or transit the PSTN.
That's why I think a large, consolidated open-source effort to build a highly complicated, robust prepaid service delivery platform from components like Kamailio/OpenSIPS is largely pointless. Otherwise I would be the first to lend it my enthusiasm.
Luciano Afranllie wrote:
On Tue, Dec 30, 2008 at 9:44 AM, Peter Lemenkov lemenkov@gmail.com wrote:
Hello!
2008/12/29 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle?
Yes. We use it in conjunction with Oracle 10g.
When I checked the project looked dead.
I would say that libsqlora8 is finished :) - it works well and therefore doesn't need to be updated.
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module.
No, we haven't tried yet.
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
Callflows
What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
- How to manage recharges?
Etc, etc.
Regards Luciano
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Alex Balashov wrote:
I think #3 is the most important and the one that is likely to prove most relevant in the short term, as I think we can all agree that there is no expectation that the PSTN in a time frame anyone would deem short to immediate term.
That is, "that the PSTN will go away."
On 12/30/08 14:45, Alex Balashov wrote:
Alex Balashov wrote:
I think #3 is the most important and the one that is likely to prove most relevant in the short term, as I think we can all agree that there is no expectation that the PSTN in a time frame anyone would deem short to immediate term.
That is, "that the PSTN will go away."
I think we talk here about a business model. While PSTN stands more for technology, Telco world will be with us, no matter they use TDM, ISDN, SIP or SIPng...
Similar to NAT, which would do security even IP address shortage would be a past, PSTN-model is a walled-garden communication environment, protecting from "buhoohalaa" threats of wide Internet.
Cheers, Daniel
I totally agree with you.
But the reality, at least in Argentina, is prepaid model is very successful because major operators don't have good flat rate options. And where the flat rate option is available, that is small communities (telco cooperatives) which are using VoIP, most of the call DO terminate in the PSTN or PLMN. This should be also the case in other parts of the world, that is why my interest.
And my initiative was not to build or design a full blown prepaid system but to share ideas and experiences about how open source software spread over there was used together to accomplish the objective of providing a prepaid solution.
Regards Luciano
On Tue, Dec 30, 2008 at 10:42 AM, Alex Balashov abalashov@evaristesys.com wrote:
It's a good thought.
My concern is that from an economic perspective, coming up with any grand, unifying schemes or projects to solve these architectural challenges is mostly a pointless waste of time.
While admittedly the prepaid model is proving to be quite a viable inroad in many parts of the world outside of the US and W. Europe (and indeed, much of the interest seems to be there), fundamentally it can only exist to the measure that:
(1) Voice switching, transport and subscriber services are billed by per-minute usage, and voice infrastructure and service delivery systems are monetised this way;
(2) The process of rebilling for usage is a derivative function of the economics of PSTN interconnection and how the PSTN TDM carrier-world business model works (a series of billable events and relatively fixed reservations of capacity) versus the Internet business model (primarily flat-rate peering and settlement-free peering among backbone haulers) that revolves around higher-order applications delivered over packets;
(3) There are not too many flat-rate alternatives available elsewhere in the telecom world.
I think #3 is the most important and the one that is likely to prove most relevant in the short term, as I think we can all agree that there is no expectation that the PSTN in a time frame anyone would deem short to immediate term.
For example, here in the US, pre-paid calling cards are largely obsolete and highly irrelevant from a mass-market perspective. They survive in various niches where people remain that are somehow sentimentally or inertially attached to calling cards and fixed-line long-distance; this includes retirees, large communities of first-generation immigrants for whom this is a viable means of making calls to their home countries relatively inexpensively, and so on. But really, by and large landline revenue is falling precipitously, everyone has a mobile, international rate plans are available for those who truly need to make a lot of international calls, and domestic long-distance is increasingly flat-rate / unlimited on fixed-line (and is already so on mobile).
For the most part, people ordering origination (DIDs) in the form of wholesale trunking are interested in flat-rate DIDs as well. Termination will remain usage-based, but only so far as points #1 and #2 above are highly operative, and only so long as private VoIP peering doesn't gain any serious traction.
All these details can be debated at great length, but the salient point here is that this is a business model that is intimately bound up with the idiosyncrasies of the PSTN and the way the incumbent voice business has functioned for almost a century.
It is fairly obvious, I think, that whenever it is that we do get around to moving beyond the PSTN, in part or in whole, the centrality and unassailable importance of "minutes" as a billing fixture will be expected to disappear in line with the ontology to which all other Internet-based application services are subject. Meanwhile, the incumbent telco world will go increasingly to flat-rate and unlimited plans and there will be continuing downward cost pressure, as well as increasing local loop deregulation and unbundling in a variety of other national markets in which state incumbents persist with varying degrees of success.
So, while this sort of stuff can probably make a decent amount of money in the US and Europe if appropriatedly positioned/marketed/specialised, and certainly can work in Latin America, the Middle East, etc., it does have the quality of being somewhat regressive and not particularly forward-thinking. It is overly connected to a shifting and unstable landscape of arbitrage opportunities arising from the position of VoIP relative to the PSTN and wireless; specifically, that most calls still terminate or transit the PSTN.
That's why I think a large, consolidated open-source effort to build a highly complicated, robust prepaid service delivery platform from components like Kamailio/OpenSIPS is largely pointless. Otherwise I would be the first to lend it my enthusiasm.
Luciano Afranllie wrote:
On Tue, Dec 30, 2008 at 9:44 AM, Peter Lemenkov lemenkov@gmail.com wrote:
Hello!
2008/12/29 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle?
Yes. We use it in conjunction with Oracle 10g.
When I checked the project looked dead.
I would say that libsqlora8 is finished :) - it works well and therefore doesn't need to be updated.
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module.
No, we haven't tried yet.
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
Callflows
What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
- How to manage recharges?
Etc, etc.
Regards Luciano
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
On 12/30/08 14:23, Luciano Afranllie wrote:
[...]
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
this is usually up to what you are more familiar to. If you go for sql-db system, then you should have in consideration the load_credentials feature provided by auth_db module. With that you can load attributes per user at authentication, saving one extra db query.
As I am designed now my systems, I have dropped a lot of modules that were hiding behind sql queries, by using config file operations (via avp_db_query() and now, with trunk, via the new sqlops module). In this way I am not stuck to a predefined db structure and can use tricks that make the sql operation faster based on server side features. sqlops module makes possible to load caller and callee profiles in one query for each and keep them for entire route processing in memory, therefore, very fast access.
- Callflows
Usually there are two scenarios 1) caller ----- proxy ----- b2bua ----- proxy ----- callee 2) caller ----- proxy ----- b2bua ----- pstn ----- callee
First is when you do prepaid for voip-to-voip and you deal with NAT, also when you have kind of sbc for the second proxy. The second is the typical case for calls terminated to pstn.
- What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
I use most of them. I go by default to Asterisk or FreeSWITCH, depending if it a more PBX-like service or carrier. SEMS is something I used a lot in the past.
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
B2BUA, all listed above are good options in certain conditions. The most important aspect is to understand scaling vs features requirements.
- How to manage recharges?
Voucher cards + IVR is an option. Payment gateways (for credit cards) + their API.
Cheers, Daniel
On Wed, Dec 31, 2008 at 7:44 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 12/30/08 14:23, Luciano Afranllie wrote:
[...]
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
this is usually up to what you are more familiar to. If you go for sql-db system, then you should have in consideration the load_credentials feature provided by auth_db module. With that you can load attributes per user at authentication, saving one extra db query.
As I am designed now my systems, I have dropped a lot of modules that were hiding behind sql queries, by using config file operations (via avp_db_query() and now, with trunk, via the new sqlops module). In this way I am not stuck to a predefined db structure and can use tricks that make the sql operation faster based on server side features. sqlops module makes possible to load caller and callee profiles in one query for each and keep them for entire route processing in memory, therefore, very fast access.
- Callflows
Usually there are two scenarios
- caller ----- proxy ----- b2bua ----- proxy ----- callee
- caller ----- proxy ----- b2bua ----- pstn ----- callee
First is when you do prepaid for voip-to-voip and you deal with NAT, also when you have kind of sbc for the second proxy. The second is the typical case for calls terminated to pstn.
- What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
I use most of them. I go by default to Asterisk or FreeSWITCH, depending if it a more PBX-like service or carrier. SEMS is something I used a lot in the past.
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
B2BUA, all listed above are good options in certain conditions. The most important aspect is to understand scaling vs features requirements.
- How to manage recharges?
Voucher cards + IVR is an option. Payment gateways (for credit cards) + their API.
Thanks Daniel for your ideas.
I just have a doubt about call flows (I made this question in another thread but still it is not clear to me).
My understanding is the call comes into the proxy and it decides to send the call to the b2bua if the caller is a prepaid user. My question is, should the b2bua or the proxy make the final routing decision? How does the b2bua know where to forward the call next? If we use routing capabilities of the b2bua then we loose the ability to use routing capabilities of the proxy.
Another approach I am thinking is one b2bua per destination so, if I want to fw the call to gw01 then in the proxy I fw the call to b2bua01, if I want to fw the call to gw02, then I fw the call to b2bua02 and so on.
Regards and Happy new yer for everybody! Luciano
On 12/31/08 16:09, Luciano Afranllie wrote:
On Wed, Dec 31, 2008 at 7:44 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 12/30/08 14:23, Luciano Afranllie wrote:
[...]
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
this is usually up to what you are more familiar to. If you go for sql-db system, then you should have in consideration the load_credentials feature provided by auth_db module. With that you can load attributes per user at authentication, saving one extra db query.
As I am designed now my systems, I have dropped a lot of modules that were hiding behind sql queries, by using config file operations (via avp_db_query() and now, with trunk, via the new sqlops module). In this way I am not stuck to a predefined db structure and can use tricks that make the sql operation faster based on server side features. sqlops module makes possible to load caller and callee profiles in one query for each and keep them for entire route processing in memory, therefore, very fast access.
- Callflows
Usually there are two scenarios
- caller ----- proxy ----- b2bua ----- proxy ----- callee
- caller ----- proxy ----- b2bua ----- pstn ----- callee
First is when you do prepaid for voip-to-voip and you deal with NAT, also when you have kind of sbc for the second proxy. The second is the typical case for calls terminated to pstn.
- What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
I use most of them. I go by default to Asterisk or FreeSWITCH, depending if it a more PBX-like service or carrier. SEMS is something I used a lot in the past.
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
B2BUA, all listed above are good options in certain conditions. The most important aspect is to understand scaling vs features requirements.
- How to manage recharges?
Voucher cards + IVR is an option. Payment gateways (for credit cards) + their API.
Thanks Daniel for your ideas.
I just have a doubt about call flows (I made this question in another thread but still it is not clear to me).
My understanding is the call comes into the proxy and it decides to send the call to the b2bua if the caller is a prepaid user. My question is, should the b2bua or the proxy make the final routing decision? How does the b2bua know where to forward the call next? If we use routing capabilities of the b2bua then we loose the ability to use routing capabilities of the proxy.
use the routing capabilities of the proxy. B2BUA can use the R-URI or certain headers added by proxy to decide where to send.
Daniel
Another approach I am thinking is one b2bua per destination so, if I want to fw the call to gw01 then in the proxy I fw the call to b2bua01, if I want to fw the call to gw02, then I fw the call to b2bua02 and so on.
Regards and Happy new yer for everybody! Luciano
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Agreed; my experience has been that it is easiest and wisest to keep the B2BUA as dumb as possible.
On Dec 31, 2008, at 9:18 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 12/31/08 16:09, Luciano Afranllie wrote:
On Wed, Dec 31, 2008 at 7:44 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 12/30/08 14:23, Luciano Afranllie wrote:
[...]
I don't know if this has been discussed earlier but it would be nice to point some key requirements for a system supporting prepaid users and possible solutions to those requirements. I think several of us is doing the same things so, we can benefit from other experience and may be we can find a pattern (of course not perfect and "fit all") for this problem using open source alternatives.
I am talking about something like this:
- How to store and retrieve user category (postpaid, prepaid, etc).
LDAP, Radius, SER groups?
this is usually up to what you are more familiar to. If you go for sql-db system, then you should have in consideration the load_credentials feature provided by auth_db module. With that you can load attributes per user at authentication, saving one extra db query.
As I am designed now my systems, I have dropped a lot of modules that were hiding behind sql queries, by using config file operations (via avp_db_query() and now, with trunk, via the new sqlops module). In this way I am not stuck to a predefined db structure and can use tricks that make the sql operation faster based on server side features. sqlops module makes possible to load caller and callee profiles in one query for each and keep them for entire route processing in memory, therefore, very fast access.
- Callflows
Usually there are two scenarios
- caller ----- proxy ----- b2bua ----- proxy ----- callee
- caller ----- proxy ----- b2bua ----- pstn ----- callee
First is when you do prepaid for voip-to-voip and you deal with NAT, also when you have kind of sbc for the second proxy. The second is the typical case for calls terminated to pstn.
- What IVR to use for user notifications (no credit, etc) and user
balance check? Asterisk, SEMS, etc?
I use most of them. I go by default to Asterisk or FreeSWITCH, depending if it a more PBX-like service or carrier. SEMS is something I used a lot in the past.
- How to enforce call tear down when credit is exhausted?
What B2BUA to use?
B2BUA, all listed above are good options in certain conditions. The most important aspect is to understand scaling vs features requirements.
- How to manage recharges?
Voucher cards + IVR is an option. Payment gateways (for credit cards) + their API.
Thanks Daniel for your ideas.
I just have a doubt about call flows (I made this question in another thread but still it is not clear to me).
My understanding is the call comes into the proxy and it decides to send the call to the b2bua if the caller is a prepaid user. My question is, should the b2bua or the proxy make the final routing decision? How does the b2bua know where to forward the call next? If we use routing capabilities of the b2bua then we loose the ability to use routing capabilities of the proxy.
use the routing capabilities of the proxy. B2BUA can use the R-URI or certain headers added by proxy to decide where to send.
Daniel
Another approach I am thinking is one b2bua per destination so, if I want to fw the call to gw01 then in the proxy I fw the call to b2bua01, if I want to fw the call to gw02, then I fw the call to b2bua02 and so on.
Regards and Happy new yer for everybody! Luciano
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Hello,
On 12/30/08 13:44, Peter Lemenkov wrote:
Hello!
2008/12/29 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 12/29/08 13:51, Peter Lemenkov wrote:
[...]
- At the time of user calls somewhere, we (after checking its auth
data) rewrite its URI using custom plugin for OpenSER (which utilizes libsqlora8 library). It's not a rocket science, and (in simplified form) it looks like the following:
Is libsqlora8 working with latest API libs from Oracle?
Yes. We use it in conjunction with Oracle 10g.
When I checked the project looked dead.
I would say that libsqlora8 is finished :) - it works well and therefore doesn't need to be updated.
good to know, thanks. It has an easier API than the native OCI libs.
Cheers, Daniel
On Monday 29 December 2008, Daniel-Constantin Mierla wrote:
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module. Probably combined with the new sqlops module in upcoming 1.5, a lot of similar operations as yours can be coded in the config file pretty easy.
Hi Daniel,
i did not received any bug reports or reports of successful usage related to db_oracle yet. I've no means to test this, as i've no access to a oracle DB. I talked with Jan Janak about this module, he also was sceptical that it works good in the current state.
Cheers,
Henning
Hi
in the same context of prepaid system iam also building with PBX Features
here is the my big question always is.
if the user register wtih Openser/ Kamailio
dial other register user. when the any one of them want to connect to conference and bring other user in to conferene
how will that work ?
any reference or clarification will be greate
Kamailio registrat and proxy asterisk as PSTN and b2bua Mediaproxy / rtpproxy iam using for NAT
Ram
The call would have to run through Asterisk on the initial setup.
You can't shunt the call legs in through a conference server afterward because the proxy can't do that; it's not a UA.
ram wrote:
Hi
in the same context of prepaid system iam also building with PBX Features
here is the my big question always is.
if the user register wtih Openser/ Kamailio
dial other register user. when the any one of them want to connect to conference and bring other user in to conferene
how will that work ?
any reference or clarification will be greate
Kamailio registrat and proxy asterisk as PSTN and b2bua Mediaproxy / rtpproxy iam using for NAT
Ram
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
On Tue, Jan 6, 2009 at 3:27 PM, Alex Balashov abalashov@evaristesys.comwrote:
The call would have to run through Asterisk on the initial setup.
You can't shunt the call legs in through a conference server afterward because the proxy can't do that; it's not a UA.
In this case if every call going via Asterisk or b2bua
so how can i use Openser capabilities of handling more users/calls
Ram
El Jueves, 8 de Enero de 2009 06:03, ram escribió:
On Tue, Jan 6, 2009 at 3:27 PM, Alex Balashov
abalashov@evaristesys.comwrote:
The call would have to run through Asterisk on the initial setup.
You can't shunt the call legs in through a conference server afterward because the proxy can't do that; it's not a UA.
In this case if every call going via Asterisk or b2bua
so how can i use Openser capabilities of handling more users/calls
It's obvious ... loadbalancing the calls between more b2bua "virtual gateways", that is how we do it.
Hello Henning,
On 01/05/09 18:23, Henning Westerholt wrote:
On Monday 29 December 2008, Daniel-Constantin Mierla wrote:
From 1.4 on, there is a dedicated driver for Oracle. Have you tried it? I wonder what is the maturity of that module. Probably combined with the new sqlops module in upcoming 1.5, a lot of similar operations as yours can be coded in the config file pretty easy.
Hi Daniel,
i did not received any bug reports or reports of successful usage related to db_oracle yet. I've no means to test this, as i've no access to a oracle DB. I talked with Jan Janak about this module, he also was sceptical that it works good in the current state.
I have been using it for testing, but in some limited use cases. All ok, I hoped maybe someone else has more insights about running it in production.
Cheers, Daniel
On Tuesday 06 January 2009, Daniel-Constantin Mierla wrote:
i did not received any bug reports or reports of successful usage related to db_oracle yet. I've no means to test this, as i've no access to a oracle DB. I talked with Jan Janak about this module, he also was sceptical that it works good in the current state.
I have been using it for testing, but in some limited use cases. All ok, I hoped maybe someone else has more insights about running it in production.
Hi Daniel,
thanks for the information.
Cheers,
Henning
-
Alex Balashov -
BERGANZ François -
Daniel-Constantin Mierla -
Henning Westerholt -
igor -
Iñaki Baz Castillo -
Luciano Afranllie -
Peter Lemenkov -
ram -
Raúl Alexis Betancor Santana