<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.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">
<div bgcolor="#FFFFFF" text="#000000">
Thanks Matt for all the valuable details -- even quite some time
since your answer, I still have to digest parts of it, given that I
had some tough cold to deal with and then a bit of traveling. But
that gave time to think more about and I have an idea that I will
present in a near future to make the trust relationship between
Kamailio and Asterisk instance a bit more dynamic.<br>
<br>
For now, I want to comment on your suggestion, pasted next:<span class=""><br>
<br>
"""<br>
From Kamailio's perspective, you could:<br>
<br>
<div>* Receive an inbound request<br>
</div>
<div>* Pick some Asterisk resource in your pool of available servers<br>
</div>
<div>* (Assuming this is done using a REST API) PUT the
configuration of the endpoint on the specific destination server<br>
</div>
<div>* Route the call to that server<br>
</div>
* Later, DELETE the configuration off the server<br>
"""<br>
<br></span>
I would prefer to avoid any extra network communication between
Kamailio and Asterisk, we have to send a sip package anyhow. It can
add delays and also complexity in dealing with transmission errors
of the PUT operation.<br>
<br>
Given you suggestion, maybe we can loop that internally in Asterisk
somehow. Have kind of SIP message pre-processing callback where to
do the PUT operation for configuration of the endpoint, then do the
normal diaplan routing. I am quite sure should be possible somehow
with the new ARI, I just need time to dig into it.<br></div></blockquote><div><br></div><div>I was thinking some more about this, and I realized that I'm not really sure how I would pick a specific Asterisk server in a pool of servers.<br><br></div><div>This is probably going to demonstrate some of my ignorance when it comes to Kamailio, but I'm going to go ahead anyway :-)<br></div><div><br>Say, for example, we have n Asterisk servers, all of which can serve any need that an inbound SIP request requires. They are generic media application servers, and Kamailio just needs to pick one and send the request to it, most likely indicating the purpose in a SIP header. Then, we may receive a request from Alice to go into a conference room:<br><br><div>INVITE <a href="mailto:sip%3Aconference@my-service-provider.com">sip:conference@my-service-provider.com</a> SIP/2.0<br></div><div>From: Alice <<a href="mailto:alice@super-awesome-company.com">alice@super-awesome-company.com</a>></div>...<br><br>And we want to proxy that request to one of our media application servers, turning it into something like this:<br><br></div><div>INVITE <a href="mailto:sip%3Aconference@asterisk-node-five.mydomain.com">sip:conference@asterisk-node-five.mydomain.com</a> SIP/2.0<br></div><div>From: Alice <<a href="mailto:alice@super-awesome-company.com">alice@super-awesome-company.com</a>></div><div>To: ...<br></div><div>X-Exec-App: Conference<br>X-Exec-App-Data: 1000<br></div><div><br></div>Any Asterisk server can then receive the request, extract the application to execute, and start the correct application, letting an ARI application do the heavy lifting of actually implementing the requested application.<br><br></div><div class="gmail_quote">exten => s,1,NoOp()<br></div><div class="gmail_quote"> same => n,Set(app=${PJSIP_HEADER(read,X-Exec-App)})<br></div><div class="gmail_quote"> same => n,Set(args=${PJSIP_HEADER(read,X-Exec-App-Data)})<br></div><div class="gmail_quote"><div> same => n,Stasis(${app}, ${args})<br></div><div> same => n,Hangup()<br><br></div><div>All of that is fine and good - but how did Kamailio choose "asterisk-node-five" as the Asterisk server to send the request to? What's more, if those servers are truly dynamic, where we are using something like OpenStack to spin up and spin down Asterisk servers on an as-needed basis, than the mere act of knowing the pool of available Asterisk server is going to be tricky. Granted, the Asterisk servers could register themselves to Kamailio, so it will know at any one time who all is available for a resource, but it feels like the Kamailio routing could get tricky, with a lot of business logic sprinkled into it.<br><br>Expanding on the snippet above, if I send another request from Bob <<a href="mailto:bob@super-awesome-company.com">bob@super-awesome-company.com</a>>, and Bob is attempting to get into the same conference room by sending a request to <a href="mailto:conference@my-service-provider.com">conference@my-service-provider.com</a>, I need to have the logic someplace that we would preferably send Bob to the same Asterisk server. Granted, two Asterisk servers can form a single conference room by connecting themselves together, but that's less efficient than having both SIP requests land on the same Asterisk server.<br><br></div><div>There may be elegant ways to handle this in Kamailio already; I'm just not sure what they would be in this scenario.<br><br>One way of handling this using Asterisk would be to have another Asterisk instance (or predictable set of Asterisk instances) act as a Redirect server. All requests that require a media application server get sent to those limited number of Asterisk servers, and they use an ARI application to perform the business logic lookups of who to forward the request onto. That Asterisk server would always return a 302 Redirect. Whether or not that removes Kamailio from the entire path or not is probably up to Kamailio to decide. But that ends up adding more communication to the path, and I'm not sure that's the right way to handle this.<br><br></div><div>At some point in time, there's going to be (a) logic that requires dynamic lookups to determine where to send a request, and (b) business logic that has to live somewhere to govern those routing rules. I do know that having all of that live or be replicated across Asterisk servers is not fantastic; my inclination right now is to pull that out of the Asterisk instances and have those kinds of lookups live outside of the communications engines. I'd be curious what other options are available in a larger system architecture.<br></div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</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>