<div dir="ltr"><font><font face="verdana,sans-serif">Hi Bogdan and Brett,</font></font><div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">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 </font><font face="courier new, monospace">dr_gateways</font><font face="verdana,sans-serif"> 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</font><font face="Verdana, sans-serif">.</font></font></div>
<div><font><font face="Verdana, sans-serif">To sum it up, I would say the desired scenario would resemble the steps below:</font></font></div><div><font><font face="Verdana, sans-serif"><br></font></font></div><div><font><font face="Verdana, sans-serif">1) OpenSIPS receives an INVITE</font></font></div>
<div><font face="Verdana, sans-serif">2) OpenSIPS asks an external system (e.g. the Perl script) for the gateways available for this specific INVITE request</font></div><div><font face="Verdana, sans-serif">3) A list of gateways is returned to OpenSIPS (based on some black-box logic)</font></div>
<div><font face="Verdana, sans-serif">4) OpenSIPS dynamically routes the INVITE to the specified gateways, prioritising based on cost, time, or ...</font></div><div><font face="Verdana, sans-serif"><br></font></div><div><font face="Verdana, sans-serif">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.</font></div>
<div><font face="Verdana, sans-serif"><br></font></div><div><font face="Verdana, sans-serif">Regards,</font></div><div><font face="Verdana, sans-serif">Shaahin</font></div><div><br></div><div><br><div class="gmail_quote">
On Thu, Aug 30, 2012 at 11:10 PM, Brett Nemeroff <span dir="ltr"><<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Maybe if you told us a little bit about your complicated business logic, we may be able to provide more guidance?</div><span class="HOEnZb"><font color="#888888"><div>-Brett</div></font></span><div class="HOEnZb">
<div class="h5"><div><br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 7:07 AM, Shaahin Madani <span dir="ltr"><<a href="mailto:shaahin.madani@gmail.com" target="_blank">shaahin.madani@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p class="MsoNormal"><br></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Verdana","sans-serif"">I understand that forwarding calls to a certain gateway
can be achieved using the </span><span lang="EN-US" style="font-family:"Courier New"">rewritehostport(…)</span><span lang="EN-US" style="font-family:"Verdana","sans-serif""> function; and
that prefix-/caller-/group-/time-/priority-based dynamic routing can be
addressed using the </span><span lang="EN-US" style="font-family:"Courier New"">DROUTING</span><span lang="EN-US" style="font-family:"Verdana","sans-serif""> module. However, in my system
what actually is “dynamic” is the gateway list itself, which is therefore not a
subset of the </span><span lang="EN-US" style="font-family:"Courier New"">dr_gateways</span><span lang="EN-US" style="font-family:"Verdana","sans-serif""> 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.</span></p><p class="MsoNormal"><br></p></div></blockquote></div></div>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div></div>