On 2009-05-03, at 20:07, Scott Lawrence wrote: > 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. > And my evil plan all along was to get You interested in this technology so that sipXecs 5.0 can benefit from AMQP bundled with CentOS/RedHat 6.0. ;)
I've spent last 3 days looking at different implementations only to discover that my favorite one (Apache QPID) is being packaged as Fedora AMQP Infrastructure or RedHat RMG (which also includes RT kernel that handles RTP better). Pity that there is no support for STOMP in this implementation. Also Java implementation is out of sync with C++ one in the current release. Anyway have a look at this url: http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes Pawel, _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
