Re: [Kamailio-Users] Scaling up asterisk using kamailio while keeping features (WAS: re-invite mid call?)

Hi all, first I want to thank you for providing answers to my numerous questions. You have made perfectly clear that Kamailio is only a proxy, and is rather good at that. Secondly, I now am rather pessimistic about scaling up our current asterisk system (which is only used by our own office) to be useful for the entire organisation. We actually use: - flash operator panel to transfer calls - call recording (mid-call using *1) - call pickup - barge-in - conferences - call forwarding - ACD functions + listening through ChanSpy - and various other things The data network people don't want all calls to flow through some central point, because of WAN network load, and think they can have phones talk to each other using g711 when they are one the same LAN, and g729 when they need to go through a WAN. But as I see it now, it will be pretty much impossible to scale up using Kamailio if we still need operator panels in offices here and there, because there is no operator panel that can manipulate calls through Kamailio (because that's only a proxy), and there is no operator panel that can handle multiple parallel asterisk installations or SEMS or whatever. Switching to different codecs depending on network location might be doable using an Kamailio extension, but that will require a lot of work, keeping a database, and manipulating the codec info in the SDP. Mid-call recording poses it's own problems. If it must go undetected then ALL calls must go through a rtp proxy, which the network people will oppose, and even if not, Kamailio will not be the proper tool to enable it. Also recording of G729 calls rules out SEMS and basically all other opensource solutions except asterisk. Of course there also is the question of managing all this. We currently edit configfiles, but that doesn't scale all too well, so we'll probably need some management and reporting tools as well. And I currently have no clue on how to do attended transfer, or call pickup on such a system, both of which seem pretty basic to me in a corporate environment. Scaling up our asterisk system while preserving all of its features seems to be a lot more involving than I initially thought... Thanks, Antonio PS: And I'd like a one-to-one chat with some guys on the asterisk mailing list who simply point to openSER when someone asks for scalability ;-)