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

Wed Feb 11 11:12:00 CST 2015

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
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.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150211/8a0c5fc7/attachment-0001.html>