Hi, I'm not a fan of the idea of having a B2B implemented in Kamailio, but at the same time I agree with Alex's reasons for having it, so I give a +1 to this. Cheers, Federico On Wed, Mar 2, 2016 at 7:01 PM, Fred Posner <fred(a)palner.com> wrote:

We'd also welcome a signaling-only B2BUA component for Kamailio, so +1 for this. Regards, Paul Am 03.03.2016 um 13:25 schrieb Alex Balashov:

Would the proposed B2BUA be based on dialog module? If so, I remember a few years ago that there were some fundamental problems with dialog module and it was proposed to design a new dialog-ng module. I haven't followed what (if anything) happened. Would the proposed B2BUA also include SBC style features, such as limiting simultaneous calls, call times, etc? Would it be possible to distribute the B2BUA to multiple parallel running servers? -- Juha

Daniel, I'd be curious to know if you have any thoughts on this, although it is of course a very controversial idea. My personal philosophical position is very much against it. It's just not what Kamailio is. However, I see demand for it _everywhere_. -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Daniel, (Yes, it was addressed to you. :-) On 03/23/2016 02:43 PM, Daniel-Constantin Mierla wrote: Fair enough. It's just that the number of people with sufficient SER core development expertise to do this is, realistically, I think, quite small. I certainly couldn't do it. Understood. What is the essence of the new 'topos' module? I am not sure I have understood it. I don't think it lacks docs so much--the Readmes embedded in the repo are actually pretty good. And it definitely performs well under high loads in my observations, especially with the SIP thread pool enabled, as discussed in Stefan's KW presentation some years ago. What it lacks unfortunately is what might be termed FOSS critical mass. The maintaining company swamped with work on their commercial endeavours and development of their flagship commercial product (understandable). The SEMS list is dead, apart from very occasional shot-in-the-dark questions answered when Stefan has limited time. A lot of the answers are kind of "go hack this in the source yourself", which is understandable too -- it's not a criticism at all. Frafos have made clear (from my vantage point) that they are not even especially interested in supporting open-source SEMS on a commercial basis per se. Perhaps I am wrong about that, though, and if anyone from Frafos would like to weigh in on that and correct me, please do. So, mostly empty mailing list, no thriving user community, conferences, or an ecosystem of O'Reilly and Packt Publishing books. You can understand why someone trying to use it seriously as critical infrastructure might look at this as a nonviable avenue for commercial support backstop and long-term technology strategy. I myself am an advocate of strongly pushing SEMS as the official companion product to Kamailio for B2BUA applications rather than building a B2BUA in Kamailio. I also think that could serve as a useful commercial pipeline to Frafos for the ABC SBC product, some percentage of such users would surely want to 'upgrade' to the 'real deal'. But I myself don't of course have the resources or time to become The SEMS Guy for these purposes, and neither do most individuals. There's a kind of spontaneous criticality effect in open-source that materialises around certain projects and not others, and so far that has not materialised around SEMS, although perhaps I am ignorant of widespread, quiet utilisation. The only major uses of it in larger commercial platforms of which I am aware are that of Sipwise, Juha Heinanen/Tutpro's OpenSIPg product, and our CSRP. My guess is that both Sipwise and Tutpro have separate commercial arrangements with Frafos for SEMS issues, so most stuff around open-source SEMS stays in the shadows. If that can change, I think their engine is definitely the most natural and complementary fit for Kamailio for these use-cases. But it's not clear who is in a position to drive such change unless it became a central ingredient of Frafos' strategy per se. The general problem with this is economic in nature rather than technical. Freeswitch is prone to deadlock around 300 CPS, so if you want to handle, say, 2000 CPS, as is not uncommon in the short-duration industry and also in larger "legitimate traffic" Installations, you need a farm of 5-10 Freeswitch boxes. That's a lot of boxes, and boxes are expensive. Kamailio can otherwise handle such throughput unproblematically on one server. I don't know how Asterisk call setup performance is these days, but I suspect it is not better than Freeswitch. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Daniel-Constantin Mierla writes: I have been sending requests out from Kamailio via SEMS, for example, if caller needs to be anonymized, if there is need to restrict parallel calls, etc. I have also implemented many services using SEMS DSM diagrams, such as voicemail, conferencing, call center, call recording, etc. All of this has worked fine, but there are some issues that I have not been able to solve, which has caused minor limitations in capabilities of some services. It would be great if also the open source version of SEMS would get more attention and new developers. -- Juha