On 11 Feb 2015, at 17:50, Matthew Jordan <mjor...@digium.com> wrote:
>
>
> On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla <mico...@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:confere...@my-service-provider.com SIP/2.0
> From: Alice <al...@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:confere...@asterisk-node-five.mydomain.com SIP/2.0
> From: Alice <al...@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
> <b...@super-awesome-company.com>, and Bob is attempting to get into the same
> conference room by sending a request to confere...@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
