<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 23, 2015 at 11:16 AM, James Cloos <span dir="ltr"><<a href="mailto:cloos@jhcloos.com" target="_blank">cloos@jhcloos.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>>>> "MJ" == Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> writes:<br>
<br>
MJ> What I'm trying to reason out is: given a set of routing constraints -<br>
MJ> which includes not only load balancing but also "application" level routing<br>
MJ> decisions - what's the appropriate place for that information to live?<br>
MJ> Particularly when you want your entire system - not just Asterisk - to be<br>
MJ> scalable?<br>
<br>
You need to use something to keep track of whether each box is reachable<br>
and what each is doing.  There a lots of ways of doing that, including<br>
custom network applications, shared networkable databases, shared nfs,<br>
et alia.<br>
<br>
Then each node needs a bit of logic to use that data to determine what<br>
to do with any given event.<br>
<br>
As one example, if a sip server gets an invite which directs on to an<br>
existing conference, it needs to know which asterisk is handling that<br>
conference, so that it can send the invite there.<br>
<br>
A shared database is required, but whether it is a custom application, a<br>
networkable db or a local db stored on a networked file systems is<br>
something anyone writing the code needs to choose.<br clear="all"></blockquote></div><br></div><div class="gmail_extra">Completely agree.<br><br></div><div class="gmail_extra">What I'm driving towards - albeit in something of a roundabout fashion - are two notions:<br></div><div class="gmail_extra">(1) Hard coding logic in application configuration does not lend itself well to scalability. Kamailio lessens the pain in certain ways - you're typically going to have fewer proxies than application servers (although, I suppose that depends on what you are doing). Also, as Olle pointed out, you can replicate information out using an htable. Or use a database. To some extent though, this is not much different than using func_odbc with Asterisk (a concept many people miss often.) At the same time, requiring direct access to a database from my routing engine/media application server does not lend itself well to expressive logic. While I've managed to push the data out of the application, I haven't necessarily done the same with the business rules.<br><br></div><div class="gmail_extra">If you approach the problem purely from a "how horizontally scalable can I make this," then ideally most of your business logic would lie outside of the routing engine (Kamailio) or the media application server (Asterisk). That may mean a web microservice architecture that exposes REST APIs for the real-time component to consume. That may mean something else. As Daniel noted, the more REST APIs you hit using a cURL module (or what
 have you), the slower things get in Kamailio. The same is true for 
Asterisk. What I'm trying to fish for is where that dividing line should occur - that is, what properly belongs to Kamailio (routing decisions) and what properly belongs to something else.<br><br></div><div class="gmail_extra">(2) Domain specific languages require domain specific knowledge. This is not necessarily a bad thing. At the same time, it's far easier to parallelize the problem of application development if you can split tasks into well defined domains that make use of tools that have a wider base of knowledge. If, for example, the logic of "who is in a conference on which server" can be answered by a REST API written in Python, or JavaScript, or something else - and does not even live on the Kamailio server - then not only does the job of the Kamailio integrator become easier, it is also becomes easier to find multiple people to help write the services that it integrates with.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Matt<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div class="gmail_signature"><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div>