On 23 Feb 2015, at 16:19, Matthew Jordan <[email protected]> wrote:
> > > On Wed, Feb 11, 2015 at 11:12 AM, Olle E. Johansson <[email protected]> wrote: > > On 11 Feb 2015, at 17:50, Matthew Jordan <[email protected]> wrote: > >> >> >> On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla <[email protected]> >> wrote: >> >> >> 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:[email protected] SIP/2.0 >> From: Alice <[email protected]> >> ... >> >> And we want to proxy that request to one of our media application servers, >> turning it into something like this: >> >> INVITE sip:[email protected] SIP/2.0 >> From: Alice <[email protected]> >> To: ... >> X-Exec-App: Conference >> X-Exec-App-Data: 1000 > No need to retarget unless your asterisk is really requiring that domain. > > True. The same questions exist even if we are sending the INVITE request to > sip:[email protected] however. > > >> >> 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. > > > I think that's a very apt comparison :-) > > The Queue application's ring strategies can be problematic. In relatively > simple scenarios they apply fairly well; with sufficient complexity, you > either have to use other mechanics to achieve the functionality you want > (say, for example, Local channel members) or you find that your ring strategy > simply isn't achievable. Sometimes, Asterisk _can_ provide you the levers to > toggle the behaviour you want; however, in many complex scenarios, it can't > give you all the functionality you desire. Ideally, you want the developer > building a system on top of Asterisk to control the business application > logic - hence, the advent of ARI. In fact, the Queue application's ring > strategy limitations were a major contributing factor in the development of > ARI. > > The same could be said here. Sure, I can use one of the many levers that > exist in the dispatcher module, and there's a reasonable chance that it will > accommodate the complexity of a particular scenario. Playing around with it > over the past few days, ds_select_dst is clearly very powerful. On the other > hand, I'm still limited to the algorithms implemented in Kamailio. While I > could write my own algorithm in C and contribute it upstream, not everyone is > a C programmer! > Which is why we have python, lua, java, perl support... > It may be given the tight timing constraints that Kamailio exists under > (which is somewhat tighter than Asterisk determining who to ring in a Call > Queue) that hardcoding the algorithms in Kamailio is the best way to do it - > but I'm curious if there are ways outside of that. Of course there are. > >> 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. > > > Or we could have Kamailio integrate with Asterisk using Corosync :-) > > The DMQ message bus module looks to be rather generic. Is there any > documentation on the actual messages published over the message bus? DMQ sip messages :-) > > >> >> Expanding on the snippet above, if I send another request from Bob >> <[email protected]>, and Bob is attempting to get into the same >> conference room by sending a request to [email protected], >> 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. > > > Ouch on the forking. That's a bit of extra traffic on the Asterisk servers! Nothing compared with the RTP traffic. That's the hard part for ASterisk. > > I think this goes back to my previous point of having "business logic" be > accessible from the routing logic in Kamailio, where that business logic is > hopefully not hardcoded in a non-scalable way. > >> >> 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. > > > > I'm not sure it's completely a non-issue. The scenario where individual > requests are logically grouped at a higher level than what a pure > load-balancing algorithm can ascertain is certainly "an issue," even if you > solved it in a particular manner. Going to a database to determine whether or > not a request should go to a particular server is certainly one way of > solving it. However, you may either have to hit that database for every > request, or you have to know in your routing that some destinations will > require that lookup - which again requires adding business related logic to > the Kamailio routing. Maybe that result is a foregone conclusion, but I'm > curious if there are other ways around it. We have a lot of tables in RAM in kamailio using htable. > > The internet is certainly not overflowing with information on this topic, at > the very least :-) > > I agree that having the load of Asterisk feed out would be interesting. We > had some discussion about this at AstriDevCon; particularly, what data items > would be needed. There was some contention around exactly what should be > available from Asterisk. Things that were listed were: > CPU usage > Channel count > Memory usage > Call quality statistics (as a secondary indicator) > Distribution of response times on requests/responses > I believe Torey mentioned that they send an INVITE request every so often and > just see what happens - which is probably similar to the OPTIONS request > pinging, although you'll get a bit more useful data out of the INVITE request. > > Can you think of anything else? SUBSCRIBE/NOTIFY format for Asterisk status. > > Are there other ways of distributing this information other than AMI/DMQ? > Asterisk also supports other mechanisms, including more standardized ones > such as Corosync, statsd, etc. Given how easy it is to build an interface on > top of the internal message bus in Asterisk, we're pretty flexible there. If > we did push more information about load out of Asterisk, it'd be nice if it > was in a standard way of consuming, such that it benefited users outside of > Kamailio as well. Use SIP! /O
-- _____________________________________________________________________ -- 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
