<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 23 Feb 2015, at 16:27, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 5:42 AM, Ben Langfeld <span dir="ltr"><<a href="mailto:ben@langfeld.me" target="_blank">ben@langfeld.me</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"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 11 February 2015 at 15:12, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><div>On 11 Feb 2015, at 17:50, Matthew Jordan <<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>> wrote:</div><br><blockquote type="cite"><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-width:1px;border-left-style:solid;border-left-color: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><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" target="_blank">sip:conference@my-service-provider.com</a> SIP/2.0<br></div><div>From: Alice <<a href="mailto:alice@super-awesome-company.com" target="_blank">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" target="_blank">sip:conference@asterisk-node-five.mydomain.com</a> SIP/2.0<br></div><div>From: Alice <<a href="mailto:alice@super-awesome-company.com" target="_blank">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></div></div></blockquote></span></div></div></blockquote></div></div><div>Why do you have Kamailio determining the app and its arguments?</div></div></div></div></blockquote><div><br></div><div>You don't; it is slightly a bad example.<br><br></div><div>What I'm trying to reason out is: given a set of routing constraints - which includes not only load balancing but also "application" level routing decisions - what's the appropriate place for that information to live? Particularly when you want your entire system - not just Asterisk - to be scalable?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><br></span><div>Is it not the case that DNS is intended to specifically solve the problem of discovering the location of a service, and that we should lean on SRV records for this info?</div><div><br></div><div>You could use Consul (<a href="https://www.consul.io/" target="_blank">https://www.consul.io/</a>) to expose the set of available Asterisk nodes for a particular service via DNS and leave it out of Kamailio entirely. I should write a blog post covering this at some point.</div></div></div></div></blockquote><div><br></div><div>Consul looks interesting. I hadn't heard of that before. Parts of it look similar to Corosync.<br><br></div><div>DNS lookups certainly could cover the case of discovery, depending on how the lookup is performed.<br></div><div><br></div></div></div></div></blockquote>It's a fine tradition to overcomplicate matters. Use SIP for discovery, make it simple, keep it simple.</div><div><br></div><div>If we make Asterisk registrations more flexible, asterisk could register as part of a service group and unregister</div><div>when it for some reason wants to leave the group.</div><div><br></div><div>/O :-)</div><br></body></html>