On Sun, 2009-05-03 at 19:39 +0200, Paweł Pierścionek wrote: > On 2009-05-03, at 19:01, Scott Lawrence wrote: > > > On Sun, 2009-05-03 at 16:09 +0200, Paweł Pierścionek wrote: > >> Hi, > >> > >> I am experimenting with RedHat's AMQP Infrasructure (Apache qpid > >> present in FC10) and am thinking of making my own > >> CallStateEventBuilder/Writed but one that is pluggable. > >> > >> There seems to be no way to have one without replacing whole > >> sipXproxy > >> binary - but maybe I can have my own SipXProxyCseObserver > >> instantiated > >> inside a dynamically loaded dummy plugin ? Is is doable from inside a > >> dummy authplugin ? > > > > It should be possible. It's also a fairly easy task to make the call > > state observer interface a plugin interface. > > > > Out of curiosity - what is it that the current interface isn't doing > > that makes you think you need a different one? > > > I am not sure I get the question. :(
What I meant to ask was whether you were interested in call state events that contained different data, or whether what you were after was the different transport. I think you answered that... > There is one thing stopping me from subclassing CallStateEventBuilder/ > Writer - I want to create a RPM package for users of sipXecs 4.0.0 not > a source code for developers or a branch. :) Hence I am looking for a > way to utilize existing plugin interface to snick in my CSE Writer > implementation. Well, as you thought, there's no way to do that for 4.0.0 unless you build and entire proxy. Even if you can use the authplugin interface (might be possible - the question has been raised before but never closely studied), you'd have to change configuration file templates for the sipXproxy in order to install those plugins (not difficult, but the change would make upgrades more complex). > As to why the current XML/DB are not enough - I need to see all > sipXecs CSEs as AMQP messages in a cluster. > Having CSEs handled by the broker would allow me to : > > 1) offload postgres on proxies by posting CSEs to the "cloud" and > collecting and processing CDRs elsewhere, possibly in other formats > (eg Radius). Yes, I can see the attraction if the message broker can ensure reliable delivery even if some nodes are down for some time. > 2) integrate with desktop applications without using SIP (next version > of our sipX CTI) > 3) build apps like Flash Operator Panel with just a few clicks in > Adobe AIR/FLEX\ Applications other than the call resolver shouldn't look at CSEs because the CSEs from any one proxy don't provide a sufficiently complete picture. For example, if a call is forwarded, it's easy for different branches to go through different proxies - if two such branches are answered close together, the observers on each would report a setup event, but only one is real - the other will be disconnected immediately. But of course the call resolver could be changed to publish the CDRs using AMQP as well to enable the kind of applications you suggest. I downloaded the AMQP specs - this is a very interesting technology. Will have to spend some more time studying it. > Also I am thinking of creating mod_amqp for FreeSwitch paired with > AMQP for call state and agent ownership (right to make routing > decision) distribution across ACD cluster :D _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
