[asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

Fri Feb 13 05:42:01 CST 2015

On 11 February 2015 at 15:12, Olle E. Johansson <oej at edvina.net> wrote:

>
> On 11 Feb 2015, at 17:50, Matthew Jordan <mjordan at digium.com> wrote:
>
>
>
> On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>>  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.
>>
>> For now, I want to comment on your suggestion, pasted next:
>>
>> """
>> From Kamailio's perspective, you could:
>>
>> * Receive an inbound request
>>  * Pick some Asterisk resource in your pool of available servers
>>  * (Assuming this is done using a REST API) PUT the configuration of the
>> endpoint on the specific destination server
>>  * Route the call to that server
>>  * Later, DELETE the configuration off the server
>> """
>>
>> 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.
>>
>> 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.
>>
>
> 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.
>
> This is probably going to demonstrate some of my ignorance when it comes
> to Kamailio, but I'm going to go ahead anyway :-)
>
> 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:
>
> INVITE sip:conference at my-service-provider.com SIP/2.0
> From: Alice <alice at super-awesome-company.com>
> ...
>
> And we want to proxy that request to one of our media application servers,
> turning it into something like this:
>
> INVITE sip:conference at asterisk-node-five.mydomain.com SIP/2.0
> From: Alice <alice at super-awesome-company.com>
> To: ...
> X-Exec-App: Conference
> X-Exec-App-Data: 1000
>
> Why do you have Kamailio determining the app and its arguments?

> No need to retarget unless your asterisk is really requiring that domain.
>
>
> 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.
>
> exten => s,1,NoOp()
>  same => n,Set(app=${PJSIP_HEADER(read,X-Exec-App)})
>  same => n,Set(args=${PJSIP_HEADER(read,X-Exec-App-Data)})
>  same => n,Stasis(${app}, ${args})
>  same => n,Hangup()
>
> All of that is fine and good - but how did Kamailio choose
> "asterisk-node-five" as the Asterisk server to send the request to?
>
> There are many ways, our dispatcher module has as many ways to dispatch
> traffic as Asterisk has
> queue algorithms.
>
> 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.
>
> We could add the new DMQ message buss to Asterisk which would make
> Kamailio aware of it.
>

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?

You could use Consul (https://www.consul.io/) 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.

> There are many ways. Kamailio monitors the cluster with OPTIONs so if you
> spin up one that was
> down, it won't take long before we send traffic.
>
>
> Expanding on the snippet above, if I send another request from Bob <
> bob at super-awesome-company.com>, and Bob is attempting to get into the
> same conference room by sending a request to
> conference at my-service-provider.com, 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.
>
> That is one area that needs some logic. I have used a realtime database
> for this with kamailio asking
> for routing. Or in another setup I just fork to all asterisk servers and
> the one that has the conference
> answers. If no one answer, I retarget the request to another uri which
> means "OPEN the damn conference"
> and target that to one specific server.
>
>
> There may be elegant ways to handle this in Kamailio already; I'm just not
> sure what they would be in this scenario.
>
> 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.
>
> Too complex.
>
>
> 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.
>
>
> Sorry, but you are discussing non-issues. At least for me.
>
> An issue in my mind would be to feed the load of one asterisk into
> kamailio to help with load-balancing algorithms. We have the data in
> Asterisk, but it's
> not in Kamailio. DMQ could be one option here, or an AMI module for
> Kamailio.
>
> /O
>
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>  --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150213/90e67867/attachment-0001.html>