Regarding the probing part, you can actually use Perl to do your probing outside opensips as well. You can use a sip stack such as sipsak to send ping messages to all your ip addresses and flip a flag in DB if they don't respond. You perl script would have to be a daemon and run in the back ground though.
Regards, Ali Pey On Tue, Sep 4, 2012 at 1:39 AM, SamyGo <[email protected]> wrote: > Please read my in-line comments. > > On Sun, Sep 2, 2012 at 5:25 PM, Shaahin Madani > <[email protected]>wrote: > >> Hi Sammy, >> >> It made perfect sense, and is actually very close to my requirement. >> Thanks for sharing your experience. Please find my replies below. >> >> > I see what you are trying to do here, get a list of gateways to be used >> for a particular destination(or any other logic) >> > and then based on that list involve the drouting module. What I can >> imagine here is this would result in something >> > like inserting the returned list into opensips first and then asking >> the module(insert into module table, refresh the >> > module list and then) to do the processing for you. >> > If you have something like above in your mind, then it will be a >> performance overhead on per call basis ! >> >> That is exactly what I had in mind, with only a small difference. I was >> hoping to find a way to let the drouting module know about the gateway >> list without going through the database channel, i.e. inserting the gateway >> list into database with every call. If I could do that, it would reduce the >> performance overhead by avoiding unnecessary queries for reloading data >> into drouting module. >> >> I can imagine these two possibilities to feed the gateway-list to the > drouting table/module is a) FIFO/MI_XML method !? b) Do some customization > with the module to connect to memcache/redis based gateway-list table and > do memcache operation from the perl script (Not easy I assume, but > much efficient than (a) ) > >> >> > I'd suggest you to go without the Drouting module, in your perl script >> do all the gateway processing and send back >> > results to opensips in AVPs and develop the "Drouting like" >> functionality in opensips. >> >> I am implementing it like this now. One feature that I believe I cannot >> implement with the combination of script+Perl is monitoring the status of >> gateway using SIP probing. I need this feature, and the only way I can >> imagine it can be activated is to let the drouting module have the list >> of all gateways (say by direct access to the external database), but then >> the drouting module would want to load the whole database entries into >> memory all the time - but, before jumping to conclusion, I'd better test >> and see the memory penalty. >> > > I think this memory load is and will always be there for all possible > solutions, just keep it out of mind. How many gateways could you possibly > have !!? 100,300 ? The feature you need (SIP probing/keepalive for gateway) > has higher priority than 1~2 MB memory consumption. > > >> >> > Though I'm not sure about your whole scenario precisely, what I can >> tell you is how I had done somewhat similar >> > setup. I had all the gateways in a different DB and was using >> OpenSIPS-RADIUS integration. RADIUS used perl >> > scripts and returned a list of sorted gateways to try. The list was >> processed in opensips in serial-forking manner. >> >> Did you have the requirement for probing too? >> > > > No, not really. The gateways are assumed to be all carries which don't > usually go down, even if they do shut down we've failure_route to route the > call out to some other carrier and keep this loop untill our carrier list > exhausts or call gets established. > > >> >> > Another possibility, that I can think for you, is tell your Drouting >> module to connect to the DB containing the table >> > with ALL the gateways in it. The perl script will just return you the >> prefixes or enough logic to be input to the DROUTING >> > functions and Drouting decides the actual gateway. (Make sure in your >> perl script you put intelligent logic which will >> > ensure that DROUTING module selects from only your desired gateways) >> >> Thanks for pointing this out. I need to feed a strict list into the >> drouting module; and the only somewhat related parameter I found is the >> gw_whitelist of the do_routing(...) function, which seems to be able to >> do the job if I can fill it with a list of gateway ID or IP values (the >> documentation<http://www.opensips.org/html/docs/modules/devel/drouting.html#id293431>doesn't >> clearly say what is expected in that parameter). >> > > http://www.opensips.org/html/docs/modules/devel/drouting.html#id293561 Well > there's your function, clearly states needs a CSV "- a comma separated > white list of gateways. This will force routing over this list of carriers > or gateways (a subset of what found in the prefix rules)." > > Just use your perl script to finalize carriers in a CSV, then return into > and AVP in opensips and use this function ! - All the gateways are already > loaded by drouting module and their statuses are maintained automatically- > All you need in your perl script is select the Active gateways fitting your > business logic. > > >> Kind regards, >> Shaahin Madani >> >> >> >> >> On Fri, Aug 31, 2012 at 4:28 PM, SamyGo <[email protected]> wrote: >> >>> Hi Shaahin, >>> >>> I see what you are trying to do here, get a list of gateways to be used >>> for a particular destination(or any other logic) and then based on that >>> list involve the drouting module. What I can imagine here is this would >>> result in something like inserting the returned list into opensips first >>> and then asking the module(insert into module table, refresh the module >>> list and then) to do the processing for you. >>> >>> If you have something like above in your mind, then it will be a >>> performance overhead on per call basis ! >>> >>> I'd suggest you to go without the Drouting module, in your perl script >>> do all the gateway processing and send back results to opensips in AVPs and >>> develop the "Drouting like" functionality in opensips. >>> >>> Though I'm not sure about your whole scenario precisely, what I can tell >>> you is how I had done somewhat similar setup. I had all the gateways in a >>> different DB and was using OpenSIPS-RADIUS integration. RADIUS used perl >>> scripts and returned a list of sorted gateways to try. The list was >>> processed in opensips in serial-forking manner. >>> >>> Another possibility, that I can think for you, is tell your Drouting >>> module to connect to the DB containing the table with ALL the gateways in >>> it. The perl script will just return you the prefixes or enough logic to be >>> input to the DROUTING functions and Drouting decides the actual gateway. >>> (Make sure in your perl script you put intelligent logic which will ensure >>> that DROUTING module selects from only your desired gateways) >>> >>> I hope I made some sense here. >>> >>> Regards, >>> Sammy >>> >>> >>> On Fri, Aug 31, 2012 at 7:55 AM, Shaahin Madani < >>> [email protected]> wrote: >>> >>>> Greetings, >>>> >>>> Thanks for the helpful replies. Presently, the list of gateways cannot >>>> be retrieved using a direct query on the external database, and hence I >>>> need the Perl script to act as the middle-ware too. Some changes in the >>>> external database may fix this, and then I would be able to use the >>>> avops module as Ali suggested, but I need to first thoroughly study >>>> all the consequences ... >>>> >>>> Regarding the bottleneck issue, I don't see any way that I can avoid >>>> the queries (or Perl). In case it turns out to be a real bottleneck, then >>>> is there any way to go around it, or will I actually be hitting an OpenSIPS >>>> limitation? >>>> >>>> Cheers, >>>> Shaahin >>>> >>>> P.S. [to Ali and Rudy]: It's "Shaahin", not "Shaheen" :-) >>>> >>>> >>>> >>>> On Fri, Aug 31, 2012 at 2:03 AM, Rudy <[email protected]> wrote: >>>> >>>>> Brett, >>>>> >>>>> Any complex logic, perl, sql or otherwise can impact performance and >>>>> create a bottleneck. Regarding the perl module in particular, I can >>>>> tell you that it works pretty well. >>>>> >>>>> Thanks in advance, >>>>> --Rudy >>>>> Dynamic Packet >>>>> Toll-Free: 888.929.VOIP ( 8647 ) >>>>> >>>>> >>>>> On Thu, Aug 30, 2012 at 11:58 AM, Brett Nemeroff <[email protected]> >>>>> wrote: >>>>> > If you can sum up the logic in an SQL query I'd recommend doing >>>>> that. If you >>>>> > can cache the results in memcache, even better. Just keep in mind >>>>> that any >>>>> > complicated logic can serve as a significant bottleneck. Depending >>>>> on your >>>>> > traffic load, that may or may not be an issue. >>>>> > >>>>> > I know there are a few recommendations for the perl module here, but >>>>> I'm not >>>>> > sure of the status of the module and if it's actively maintained. >>>>> I'd love >>>>> > to hear from others about their own experiences using it. I haven't >>>>> used it >>>>> > myself in maybe 6 years or so. >>>>> > -Brett >>>>> > >>>>> > >>>>> > On Thu, Aug 30, 2012 at 9:09 AM, Shaahin Madani < >>>>> [email protected]> >>>>> > wrote: >>>>> >> >>>>> >> Hi Bogdan and Brett, >>>>> >> >>>>> >> Thanks for your replies. The issue here is that my OpenSIPS simply >>>>> does >>>>> >> not have the list of gateways, that is the gateways are *not* >>>>> available in >>>>> >> the dr_gateways table. For every INVITE request, the list of >>>>> gateways must >>>>> >> be dynamically built, and only afterwards the actual dynamic >>>>> routing can >>>>> >> take place. The logic behind building the list of gateways relies >>>>> on a >>>>> >> totally separate database. >>>>> >> To sum it up, I would say the desired scenario would resemble the >>>>> steps >>>>> >> below: >>>>> >> >>>>> >> 1) OpenSIPS receives an INVITE >>>>> >> 2) OpenSIPS asks an external system (e.g. the Perl script) for the >>>>> >> gateways available for this specific INVITE request >>>>> >> 3) A list of gateways is returned to OpenSIPS (based on some >>>>> black-box >>>>> >> logic) >>>>> >> 4) OpenSIPS dynamically routes the INVITE to the specified gateways, >>>>> >> prioritising based on cost, time, or ... >>>>> >> >>>>> > >>>>> > _______________________________________________ >>>>> > Users mailing list >>>>> > [email protected] >>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
