A Dynamic List of Gateways

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

A Dynamic List of Gateways

shaahin

Greetings,


In my OpenSIPS server, when I receive an INVITE requests, I need to (1) consult an external database to get a list of gateways, and (2) send the request to those gateways, in order, starting from the first and trying the next only if the current one fails (e.g. irresponsive, offline, busy, etc).


I understand that forwarding calls to a certain gateway can be achieved using the rewritehostport(…) function; and that prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed using the DROUTING module. However, in my system what actually is “dynamic” is the gateway list itself, which is therefore not a subset of the dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways due to the complex business-logic involved. The dynamic gateway list, nevertheless, needs to be treated identical to an ordinary one, i.e. prefix, time and priority of gateways must be considered.


Solving this problem, I assume, requires either writing a whole new DROUTING module, which wraps the necessary business-logic and consults the external database; or wrapping the business-logic in a Perl script that is called from the routing script (opensips.cfg). Now, there are two issues that I would like to know your expert opinion about:


1. Is my solution, i.e. using the Perl script to wrap the business logic and queries to the external database, the best possible way to do this?


2. As the list of gateways is dynamic, is there any way to leverage the facilities offered by the DROUTING module? Specifically, can I somehow get the list of gateways from the Perl script and pass it to the DROUTING module for prefix-/time-/priority-based routing, or probing, purposes?


Regards,

Shaahin Madani


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Bogdan-Andrei Iancu-2
Hi Shaahin,

Why not simply using the Dynamic Routing module :
        http://www.opensips.org/html/docs/modules/1.8.x/drouting.html

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 08/30/2012 03:07 PM, Shaahin Madani wrote:

Greetings,


In my OpenSIPS server, when I receive an INVITE requests, I need to (1) consult an external database to get a list of gateways, and (2) send the request to those gateways, in order, starting from the first and trying the next only if the current one fails (e.g. irresponsive, offline, busy, etc).


I understand that forwarding calls to a certain gateway can be achieved using the rewritehostport(…) function; and that prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed using the DROUTING module. However, in my system what actually is “dynamic” is the gateway list itself, which is therefore not a subset of the dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways due to the complex business-logic involved. The dynamic gateway list, nevertheless, needs to be treated identical to an ordinary one, i.e. prefix, time and priority of gateways must be considered.


Solving this problem, I assume, requires either writing a whole new DROUTING module, which wraps the necessary business-logic and consults the external database; or wrapping the business-logic in a Perl script that is called from the routing script (opensips.cfg). Now, there are two issues that I would like to know your expert opinion about:


1. Is my solution, i.e. using the Perl script to wrap the business logic and queries to the external database, the best possible way to do this?


2. As the list of gateways is dynamic, is there any way to leverage the facilities offered by the DROUTING module? Specifically, can I somehow get the list of gateways from the Perl script and pass it to the DROUTING module for prefix-/time-/priority-based routing, or probing, purposes?


Regards,

Shaahin Madani

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Brett Nemeroff
In reply to this post by shaahin
You haven't really said why the drouting module won't work. Why do you say the system won't know the gateway list itself? Where is this complicated business logic?

Chances are between memcache and db queries you can do what you want. If you want to use drouting to store the gateway list, but not use the dr_rules logic, you can sort of do that as well, but you'll have to play tricks with what rules you use. 

Also if the gateway's IPs are changing and the dr_gateways/dr_carriers tables don't meet your needs, you could always use the attrs column or even the gw_id_avp/rule_id_avp/carrier_id_avp to simply look something else up and just ignore (read: rewrite on your own) the destination.

I'm not sure how you are proposing to use your perl module. I wouldn't use the exec module for any realtime in call lookups *ever* (and I'm a big perl fan). The perl module is pretty cool, but I don't think it's maintained and you won't get the best performance from it I don't think (would love to hear other's opinions here).

Maybe if you told us a little bit about your complicated business logic, we may be able to provide more guidance?
-Brett


On Thu, Aug 30, 2012 at 7:07 AM, Shaahin Madani <[hidden email]> wrote:


I understand that forwarding calls to a certain gateway can be achieved using the rewritehostport(…) function; and that prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed using the DROUTING module. However, in my system what actually is “dynamic” is the gateway list itself, which is therefore not a subset of the dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways due to the complex business-logic involved. The dynamic gateway list, nevertheless, needs to be treated identical to an ordinary one, i.e. prefix, time and priority of gateways must be considered.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

shaahin
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 ...

I wonder whether in step (3) the list can actually be returned to OpenSIPS for further processing in the script, or both steps (3) and (4) must be implemented in the Perl script. Anyway, that is the desired scenario, which must be changed according to the limitations. Any guidance would be much appreciated.

Regards,
Shaahin


On Thu, Aug 30, 2012 at 11:10 PM, Brett Nemeroff <[hidden email]> wrote:
You haven't really said why the drouting module won't work. Why do you say the system won't know the gateway list itself? Where is this complicated business logic?

Chances are between memcache and db queries you can do what you want. If you want to use drouting to store the gateway list, but not use the dr_rules logic, you can sort of do that as well, but you'll have to play tricks with what rules you use. 

Also if the gateway's IPs are changing and the dr_gateways/dr_carriers tables don't meet your needs, you could always use the attrs column or even the gw_id_avp/rule_id_avp/carrier_id_avp to simply look something else up and just ignore (read: rewrite on your own) the destination.

I'm not sure how you are proposing to use your perl module. I wouldn't use the exec module for any realtime in call lookups *ever* (and I'm a big perl fan). The perl module is pretty cool, but I don't think it's maintained and you won't get the best performance from it I don't think (would love to hear other's opinions here).

Maybe if you told us a little bit about your complicated business logic, we may be able to provide more guidance?
-Brett


On Thu, Aug 30, 2012 at 7:07 AM, Shaahin Madani <[hidden email]> wrote:


I understand that forwarding calls to a certain gateway can be achieved using the rewritehostport(…) function; and that prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed using the DROUTING module. However, in my system what actually is “dynamic” is the gateway list itself, which is therefore not a subset of the dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways due to the complex business-logic involved. The dynamic gateway list, nevertheless, needs to be treated identical to an ordinary one, i.e. prefix, time and priority of gateways must be considered.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Ali Pey
Hi Shaheen,

Does the external system have the list of gateways in a DB of any sort? In another word, can you lookup the list of gateways with a SQL query?

You can use avops module to do a db query to retrieve the list of gateways in the desired order and route the calls in that order. Other than that, Perl would be your best friend here.

Regards,
Ali Pey


On Thu, Aug 30, 2012 at 10:09 AM, Shaahin Madani <[hidden email]> 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 ...

I wonder whether in step (3) the list can actually be returned to OpenSIPS for further processing in the script, or both steps (3) and (4) must be implemented in the Perl script. Anyway, that is the desired scenario, which must be changed according to the limitations. Any guidance would be much appreciated.

Regards,
Shaahin


On Thu, Aug 30, 2012 at 11:10 PM, Brett Nemeroff <[hidden email]> wrote:
You haven't really said why the drouting module won't work. Why do you say the system won't know the gateway list itself? Where is this complicated business logic?

Chances are between memcache and db queries you can do what you want. If you want to use drouting to store the gateway list, but not use the dr_rules logic, you can sort of do that as well, but you'll have to play tricks with what rules you use. 

Also if the gateway's IPs are changing and the dr_gateways/dr_carriers tables don't meet your needs, you could always use the attrs column or even the gw_id_avp/rule_id_avp/carrier_id_avp to simply look something else up and just ignore (read: rewrite on your own) the destination.

I'm not sure how you are proposing to use your perl module. I wouldn't use the exec module for any realtime in call lookups *ever* (and I'm a big perl fan). The perl module is pretty cool, but I don't think it's maintained and you won't get the best performance from it I don't think (would love to hear other's opinions here).

Maybe if you told us a little bit about your complicated business logic, we may be able to provide more guidance?
-Brett


On Thu, Aug 30, 2012 at 7:07 AM, Shaahin Madani <[hidden email]> wrote:


I understand that forwarding calls to a certain gateway can be achieved using the rewritehostport(…) function; and that prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed using the DROUTING module. However, in my system what actually is “dynamic” is the gateway list itself, which is therefore not a subset of the dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways due to the complex business-logic involved. The dynamic gateway list, nevertheless, needs to be treated identical to an ordinary one, i.e. prefix, time and priority of gateways must be considered.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Rudy
Shaheen,

 Look into the opensips perl module. You can execute your logic in
there, then do serial forking.

Regards,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )


On Thu, Aug 30, 2012 at 10:48 AM, Ali Pey <[hidden email]> wrote:

> Hi Shaheen,
>
> Does the external system have the list of gateways in a DB of any sort? In
> another word, can you lookup the list of gateways with a SQL query?
>
> You can use avops module to do a db query to retrieve the list of gateways
> in the desired order and route the calls in that order. Other than that,
> Perl would be your best friend here.
>
> Regards,
> Ali Pey
>
>
> On Thu, Aug 30, 2012 at 10:09 AM, Shaahin Madani <[hidden email]>
> 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 ...
>>
>> I wonder whether in step (3) the list can actually be returned to OpenSIPS
>> for further processing in the script, or both steps (3) and (4) must be
>> implemented in the Perl script. Anyway, that is the desired scenario, which
>> must be changed according to the limitations. Any guidance would be much
>> appreciated.
>>
>> Regards,
>> Shaahin
>>
>>
>> On Thu, Aug 30, 2012 at 11:10 PM, Brett Nemeroff <[hidden email]>
>> wrote:
>>>
>>> You haven't really said why the drouting module won't work. Why do you
>>> say the system won't know the gateway list itself? Where is this complicated
>>> business logic?
>>>
>>> Chances are between memcache and db queries you can do what you want. If
>>> you want to use drouting to store the gateway list, but not use the dr_rules
>>> logic, you can sort of do that as well, but you'll have to play tricks with
>>> what rules you use.
>>>
>>> Also if the gateway's IPs are changing and the dr_gateways/dr_carriers
>>> tables don't meet your needs, you could always use the attrs column or even
>>> the gw_id_avp/rule_id_avp/carrier_id_avp to simply look something else up
>>> and just ignore (read: rewrite on your own) the destination.
>>>
>>> I'm not sure how you are proposing to use your perl module. I wouldn't
>>> use the exec module for any realtime in call lookups *ever* (and I'm a big
>>> perl fan). The perl module is pretty cool, but I don't think it's maintained
>>> and you won't get the best performance from it I don't think (would love to
>>> hear other's opinions here).
>>>
>>> Maybe if you told us a little bit about your complicated business logic,
>>> we may be able to provide more guidance?
>>> -Brett
>>>
>>>
>>> On Thu, Aug 30, 2012 at 7:07 AM, Shaahin Madani
>>> <[hidden email]> wrote:
>>>>
>>>>
>>>> I understand that forwarding calls to a certain gateway can be achieved
>>>> using the rewritehostport(…) function; and that
>>>> prefix-/caller-/group-/time-/priority-based dynamic routing can be addressed
>>>> using the DROUTING module. However, in my system what actually is “dynamic”
>>>> is the gateway list itself, which is therefore not a subset of the
>>>> dr_gateways table. In fact, OpenSIPS has no idea about the list of gateways
>>>> due to the complex business-logic involved. The dynamic gateway list,
>>>> nevertheless, needs to be treated identical to an ordinary one, i.e. prefix,
>>>> time and priority of gateways must be considered.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Brett Nemeroff
In reply to this post by shaahin
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 <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Rudy
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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

shaahin
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

SamyGo
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Brett Nemeroff
In reply to this post by shaahin
What kind of traffic are you expecting? In CPS?

It may not be an issue.
-Brett


On Thu, Aug 30, 2012 at 9:55 PM, Shaahin Madani <[hidden email]> 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?


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Ali Pey
In reply to this post by shaahin
My apologies Shaahin for misspelling your name. I actually know this name very well and should have paid more attention :)

Good luck with your design, sounds like you have some exciting time ahead of you.

Regards,
Ali Pey

On Thu, Aug 30, 2012 at 10:55 PM, Shaahin Madani <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

shaahin
In reply to this post by SamyGo
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'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. 


> 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?


> 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 doesn't clearly say what is expected in that parameter). 

Kind regards,
Shaahin Madani




On Fri, Aug 31, 2012 at 4:28 PM, SamyGo <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

SamyGo
Please read my in-line comments.

On Sun, Sep 2, 2012 at 5:25 PM, Shaahin Madani <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

Ali Pey
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 <[hidden email]> wrote:
Please read my in-line comments.

On Sun, Sep 2, 2012 at 5:25 PM, Shaahin Madani <[hidden email]> 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: A Dynamic List of Gateways

shaahin
Thanks to everyone for the helpful advices :-)

Cheers,
Shaahin


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users