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

[Matthew Jordan]

On Fri, Feb 13, 2015 at 5:42 AM, Ben Langfeld <ben at langfeld.me> wrote:

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

You don't; it is slightly a bad example.

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?


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

Consul looks interesting. I hadn't heard of that before. Parts of it look
similar to Corosync.

DNS lookups certainly could cover the case of discovery, depending on how
the lookup is performed.

I'd definitely be interested in how you are using it.

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150223/c2fd013d/attachment-0001.html>