Unveiling the design for OpenSIPS 2.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Unveiling the design for OpenSIPS 2.0

Bogdan-Andrei Iancu
Hi all,

After words come the facts.  Following the discussions and the
suggestions about the new OpenSIPS design, the work in that direction
started.

The first step was to synthesize all the information and to come up with
a realistic proposal for a new design - a design that will address all
the know issue and requests.

After couple of months of discussions, investigations and meetings, the
draft for the new design was put together - a combination between
simplicity, scalability and flexibility - a full technical description
of the can be found at
          http://www.opensips.org/Development/NewDesignDescription

The main actors behind the new design are:
   Bogdan-Andrei Iancu
   Dan Pascu
   Andrei Dragus
   Anca Vamanu

The implementation work is already planned (timeline and manpower) and
ready to kick off.  Of course, this will impact on the current release
policy of the project, but all the changes in the area will be the
subject of a different email.

We encourage as many people as possible to read the draft and to comment
on it. Next step will be presenting a description of the core internals
(threading, level, APIs, flow).

Best regards,
Bogdan

--
Bogdan-Andrei Iancu
www.voice-system.ro


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Unveiling the design for OpenSIPS 2.0

Stanisław Pitucha
Hi,
I think I asked a too specific question on #vuc today, but I'm
actually interested in the answer... I've found versions <=1.6 not
very hacker-friendly. Even though the API is quite simple and you can
find many examples of usage, to test any change you have to basically
setup a test environment and replicate the traffic via either normal
phones, or sipp-like software. That's not really optimal. Even
compiling opensips with an alternative main() gives many problems when
linking.
I managed to create a patch, that I'm using to free opensips from
current limitations a little bit and test specific module
functionality on a provided message in a 100% repeatable way. (check
http://bitbucket.org/viraptor/opensips_autocheck/ if you're
interested) But that's a bit hackish solution.
Is there any plan to look at opensips 2.0 and make it more testable /
less monolithic (in any way)? I'd kill for example for a possibility
to pass a message through a specific layer / module / route without
any network interaction - just: packet in, routing decision / content
changes out. I think if would help a lot in many situations from
regression testing to verification to easier reproducing memory leaks.
Did that point... let's say, occur on any 2.0 development schedule?

--
KTHXBYE,

Stanisław Pitucha, Gradwell Voip Engineer

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Unveiling the design for OpenSIPS 2.0

Bogdan-Andrei Iancu
Hi Stan,

Stanisław Pitucha wrote:
> Hi,
> I think I asked a too specific question on #vuc today, but I'm
> actually interested in the answer
well, here is the right place for the questions :)
> ... I've found versions <=1.6 not
> very hacker-friendly. Even though the API is quite simple and you can
> find many examples of usage, to test any change you have to basically
> setup a test environment and replicate the traffic via either normal
> phones, or sipp-like software.
yes, that is true and I can say it from my own experience
> That's not really optimal. Even
> compiling opensips with an alternative main() gives many problems when
> linking.
> I managed to create a patch, that I'm using to free opensips from
> current limitations a little bit and test specific module
> functionality on a provided message in a 100% repeatable way. (check
> http://bitbucket.org/viraptor/opensips_autocheck/ if you're
> interested) But that's a bit hackish solution.
>  
let me check this - but can you briefly explain what you tried to do there?
> Is there any plan to look at opensips 2.0 and make it more testable /
> less monolithic (in any way)? I'd kill for example for a possibility
> to pass a message through a specific layer / module / route without
> any network interaction - just: packet in, routing decision / content
> changes out. I think if would help a lot in many situations from
> regression testing to verification to easier reproducing memory leaks.
> Did that point... let's say, occur on any 2.0 development schedule?
>  
I like the idea, and I would really like to do a brain storming on this,
to see what should be the right approach on this.


Right now, as working on the net/transport layer, the protocols are
defined as dynamic libs exporting some API (like function to init
socket, read, write). So, you can build a dummy proto to take messages
from files or something like that - that will make much easier to inject
a package into opensips.

Regards,
Bogdan

--
Bogdan-Andrei Iancu
www.voice-system.ro


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users