[OpenSIPS-Users] A Dynamic List of Gateways

Tue Sep 4 07:39:05 CEST 2012

Please read my in-line comments.

On Sun, Sep 2, 2012 at 5:25 PM, Shaahin Madani <shaahin.madani at gmail.com>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 <govoiper at gmail.com> 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 <shaahin.madani at gmail.com
>> > 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 <rudy at dynamicpacket.com> 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 <brett at nemeroff.com>
>>>> 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 <
>>>> shaahin.madani at gmail.com>
>>>> > 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
>>>> > Users at lists.opensips.org
>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120904/6a6536c8/attachment-0001.htm>