[Spce-user] API for getting current calls status?

[Klaus Peter v. Friedeburg]

Hi Andreas,

ok I think we have different approaches to the database. My solution is to build up a MySQL Cluster ore using tungsten-replicator for Multi-Master Replication for all proxy-nodes so that all nodes of the ng Cluster works with the same database tables. We have do this so that we can update a proxy-node ore restart the kamailio-service without any outage.
We use an other usrloc module which support the use of the same table in all of the proxy-nodes without any datacollision. 
The advantage of using a database-query is, that you see "broken" calls where the second acc-record (stop) is missing. In some circumstances we see that some Bye-Messages are not probably handled so that "broken" accounting entrys exist.

But I will take a look in the XMLDispatcher Doku so my solution need some optimization :-)

Klaus Peter

> -----Ursprüngliche Nachricht-----
> Von: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von
> Andreas Granig
> Gesendet: Donnerstag, 11. Oktober 2012 11:35
> An: spce-user at lists.sipwise.com
> Betreff: Re: [Spce-user] API for getting current calls status?
> 
> Hi,
> 
> On 10/11/2012 11:09 AM, Klaus Peter v. Friedeburg wrote:
> > when I see it right you get the data form kamailio FIFO via kamctrl. But
> > what happens when using more than one proxy for load balancing and
> > rendundancing?
> 
> This is not exactly a valid point for a stock CE, but see my comments below:
> 
> > I think the only right way is to get the information from the database
> > where active calls are logged (kamailio.acc).
> >
> > My solution is to take a look on kamailio.acc for active calls.
> 
> You'd still need to query all your kamailio.acc tables, like you'd need
> to do with XMLDispatcher, however XMLDispatcher - beside other things
> like sync/async requests - already supports querying more than one proxy
> (the "dispatch" function in XMLDispatcher.pm has a detailed
> documentation on that).
> 
> So Matt's approach is the more elegant one from my point of view,
> because it allows easy expansion to query more than one proxy.
> 
> For our up-scaled carrier solutions, which transparently supports
> multiple pairs of PROs, we've a dedicated provisioning middleware which
> routes API calls to the pair which serves the user, so in this case
> Matt's approach would work out of the box as well, because in this case
> the serving node has only one proxy running (like a CE in active/standby
> mode).
> 
> The good thing about open source though is that everyone can do it the
> way it suits him best :)
> 
> Andreas