On 23 Feb 2015, at 16:27, Matthew Jordan <[email protected]> wrote:
> > > On Fri, Feb 13, 2015 at 5:42 AM, Ben Langfeld <[email protected]> wrote: > On 11 February 2015 at 15:12, 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: >> 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:[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 > > 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. > It's a fine tradition to overcomplicate matters. Use SIP for discovery, make it simple, keep it simple. If we make Asterisk registrations more flexible, asterisk could register as part of a service group and unregister when it for some reason wants to leave the group. /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
