On 11 February 2015 at 15:12, Olle E. Johansson <o...@edvina.net> wrote:
> > 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 > > 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 < > 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 >
-- _____________________________________________________________________ -- 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