Hello all,
recently some statement came to my attention that "there is a common consent that the current design/architecture of [..] OpenSER (inherited from SER) is no longer able to deliver and to meet the present requirements and demands".
I don't want to argue that much about this opinion, in fact the demands to a Voice over IP solution depends very much on the certain setup. But i want to share some details from my experiences in developing and operating a big VoIP infrastructure here at 1&1.
We've about 2 million customers on our platform, that uses over 5 million individual numbers and terminate about 1 billion minutes per month. We're able to provide a good service with the actual architecture of OpenSER without any real problems. Of course there is always some room for improvements, but so far the main challenges we faced were not in the scalability or performance areas. More important issues are e.g. the inherent complexity of the SIP protocol and the maintainance of a good quality assurance and integration process.
We started some years ago with OpenSER 0.9.5, which we then extended a lot in house. For example we implemented more than 25 own modules, a own path implementation, did a lot of bug fixing and workarounds for certain problems we've found. We're able to reduce this amount of proprietary code a lot in the past, because of progress in the OpenSER development, intregration of our "key" modules and a lot of other contributions. We're using now something between OpenSER 1.3 and Kamailio 1.4 with only a few private extensions.
So in my opinion the actual design of our server is not "[..] an inevitable dead-end that needs to be avoided.". I rather think that we'll be able with continuing improvements to tackle the upcoming challenges well, especially as we will work together in the future with the SER developers in improving important areas of this software.
But this is just my personal opinion, everybody is of course free to have their own position.
With best regards,
Henning Westerholt
From a customer point of view is great that you are satisfied with the software.
Myself as a platform vendor having to satisfy the needs of multiple customers I can only concur with Bogdan that the curent design has flaws inherited from the original requirements and fixing them one by one by developing or improving modules to navigate around them is not the most efficient way forward.
A consistent core with a generic API to a higher level application that does not depend much on the core version and where a programming language chosen by the customer can be used is much more future proof then patching endlessly the existing code with lose modules and having to rewrite the configuration with every major version upgrade.
Having two projects and two ways to achieve the same goals may help the customers in the future.
Adrian
On Nov 14, 2008, at 2:59 PM, Henning Westerholt wrote:
Hello all,
recently some statement came to my attention that "there is a common consent that the current design/architecture of [..] OpenSER (inherited from SER) is no longer able to deliver and to meet the present requirements and demands".
I don't want to argue that much about this opinion, in fact the demands to a Voice over IP solution depends very much on the certain setup. But i want to share some details from my experiences in developing and operating a big VoIP infrastructure here at 1&1.
We've about 2 million customers on our platform, that uses over 5 million individual numbers and terminate about 1 billion minutes per month. We're able to provide a good service with the actual architecture of OpenSER without any real problems. Of course there is always some room for improvements, but so far the main challenges we faced were not in the scalability or performance areas. More important issues are e.g. the inherent complexity of the SIP protocol and the maintainance of a good quality assurance and integration process.
We started some years ago with OpenSER 0.9.5, which we then extended a lot in house. For example we implemented more than 25 own modules, a own path implementation, did a lot of bug fixing and workarounds for certain problems we've found. We're able to reduce this amount of proprietary code a lot in the past, because of progress in the OpenSER development, intregration of our "key" modules and a lot of other contributions. We're using now something between OpenSER 1.3 and Kamailio 1.4 with only a few private extensions.
So in my opinion the actual design of our server is not "[..] an inevitable dead-end that needs to be avoided.". I rather think that we'll be able with continuing improvements to tackle the upcoming challenges well, especially as we will work together in the future with the SER developers in improving important areas of this software.
But this is just my personal opinion, everybody is of course free to have their own position.
With best regards,
Henning Westerholt
-- Henning Westerholt - Development Consumer Products / DSL Core 1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen - Aufsichtsratsvorsitzender: Michael Scheeren Amtsgericht Montabaur / HRB 6484
Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-
Adrian Georgescu -
Henning Westerholt