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

[Matthew Jordan]

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

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

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.

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.

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.

-- 
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/20150211/c9e03683/attachment-0001.html>