[OpenSIPS-Users] A Dynamic List of Gateways

Ali Pey alipey at gmail.com
Tue Sep 4 15:37:16 CEST 2012 

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 <govoiper at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/81dbdf16/attachment-0001.htm>

More information about the Users mailing list