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@palner.com wrote:

On 03/02/2016 12:45 PM, Alex Balashov wrote:

...

Hi,

I wanted to raise the possibility of an inline signalling-only B2BUA component to Kamailio.

+1 for this... for many reasons including seeing what happens when the following threshold is met:

...

I myself am philosophically opposed to a B2BUA in Kamailio to the threshold of physical violence.

-- Alex

Fred Posner The Palner Group, Inc. http://www.palner.com (web) +1-224-334-FRED (3733) direct

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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:

‎The idea of a B2BUA is even more revolting when you consider that the overwhelming preponderance of people who have a topology concealment need have business models based solely on information asymmetries and arbitrage. If the only thing you've got going for you is that you can buy at one price and sell at an ever-so-slightly higher one, you should do something else.

But that doesn't stop people from a) thinking there's money in it and b) going to OpenSIPS when they find Kamailio doesn't give them what they want.

There is also the matter of 'topoh'. It's one of those things that, in theory, should work well for this case, but in practice often doesn't, perhaps due to lack of proper RR support on all sides in all cases. I can't really say why, I just know that when I've tried to deploy it for customers that insist on fitting some sort of "topology condom" over their switch platform, it's led to call duration and billing reconciliation differences in the thousands of USD. ‎ -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Sent from my BlackBerry.

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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_.

Daniel,

(Yes, it was addressed to you. :-)

On 03/23/2016 02:43 PM, Daniel-Constantin Mierla wrote:

I haven't rejected any patch with new features in kamailio that doesn't have significant impact on performance and doesn't break existing and expected functionality. So anyone is welcome to bring in code ...

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.

Otherwise, besides (hopping to) getting the new topos module in good shape as a topology (stripping) firewall, I have no business plans that would push me to invest resources in a b2bua.

Understood. What is the essence of the new 'topos' module? I am not sure I have understood it.

You said sems is calable but lacks docs, I guess that is less time consuming to sort out for someone really interested given it is open source than implementing something from scratch.

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.

Also Asterisk or FreeSwitch can scale pretty well if time is invested to optimize their config, besides using dispatcher to build a farm of them...

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

Daniel-Constantin Mierla writes:

You said sems is calable but lacks docs, I guess that is less time consuming to sort out for someone really interested given it is open source than implementing something from scratch.

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