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

Matt Van Veenendaal matt at curiousminds.com
Thu Oct 11 12:51:14 EDT 2012


Thanks so much for the feedback guys,  

I was under the impression that kamailio didn't record any dialog accounting into the database unless you turn the flag on and take a rather large performance hit on the proxy side. Since I only want to check if a user is on the line in rare circumstances, I opted to use the in memory rpc call.

Awesome to hear about the XMLDispatcher routing, that's great that it will work out of the box in the PRO solution :)  
--  
Matt Van Veenendaal


On Thursday, October 11, 2012 at 3:00 AM, Klaus Peter v. Friedeburg wrote:

> 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 (mailto: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
>  
>  
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com (mailto:Spce-user at lists.sipwise.com)
> http://lists.sipwise.com/listinfo/spce-user
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121011/00d0d4f7/attachment-0001.html>


More information about the Spce-user mailing list