[sr-dev] Migration of Open IMS Core to sip-router

[Jan Janak]

On Thu, Jul 23, 2009 at 7:59 PM, Dragos
Vingarzan<dragos.vingarzan at gmail.com> wrote:
> Hi devs,
>
> so, after many months, finally I found the time (and courage  ;-)  ) to do
> the necessary changes so that the Open IMS Core modules would also be
> runnable under sip-router. And well, kudos for the work that you've done so
> far! Adapting was really much more easy then I expected, due to the
> backwards compatibility that is still there. I was actually able so far to
> modify my modules so that they would be compilable under both
> sip-router/master and our ser_ims.

Wow, that's a bold move! Knowing that it is relatively easy to migrate
such stuff to sip-router is very encouraging, thanks.

> Until now I have managed to have the Diameter module and the I-CSCF working,
> with the rest hopefully coming in the next days. These fixes are already
> commited on our svn tree, but they are not really usable without some
> sip-router patches that I will talk about a bit later.
>
> But first of all, let me tell you the overall picture of what we have
> changed and added to SER 2.1.0 (I know it's an ancient version, but it was
> more than enough for what we wanted to get).
>
>
> Modules:
>  * cdp - The CDiameterPeer
>  * icscf - I-CSCF functions
>  * isc - IMS Service Control - AS triggering and forwarding
>  * mgcf - some helpers for making some MGCF nodes attached to
>    softswitches (this is just an experimental collection of hacks)
>  * pcscf - P-CSCF functions
>  * scscf - S-CSCF functions
>
> Other patches:
>  * dialog - small typos

I guess this one should go in right away.

>  * enum - support for query on the originating side, useful in PSTN
>    inbound processing

Could you send this patch to the mailing list and cc Juha?

>  * ratelimit - a much extended ratelimit module, with multiple
>    queues, dynamic limiting capabilities based on internal/external
>    indicators, random retry-after capabilities, etc; which although
>    sent towards the SER trunk, never made it

I think your improvements made it to the kamailio version which now
resides in sip-router/modules_k/ratelimit. Please try to see if it
contains everything that you need. If yes then we can adopt the
kamailio version of the module and junk the ser version (and move the
module from modules_k to modules directory).

>  * tls - some hashing functions

I'd be happy to see how we can integrate it into the tls module if you
send me a patch.

>  * tm - not really sure for now, but I hope we can reconcile without
>    changes on the sip-router side
>  * Core - support for emergency URI, some mem logging improvements, etc.

OK, I guess we would need more information on these two.

> I hope that we could integrate as much as possible from the changes that we
> did as really we would like to converge rather than go our own separate
> path. Sure, many parts are crazy-experimental and they would probably stay
> like that unless someone would like to do a serious re-implementation, but
> others I think would benefit outside of the IMS targets that we had.
>
> And here comes my first issue then. Whether you guys would be open to host
> this in the same git repository or should we still maintain our own separate
> svn tree? I started by adding a modules_osims directory and putting there
> the differences. And so far it seems to be working for me locally. Sure that
> the crazy-experimental parts won't make it to master, but hopefully the Open
> IMS Core could leave entirely as just one modules directory inside
> sip-router tree.
>
> If we'd stay separated, I would then try and find a way to link the git
> repository as external in our svn one and overwrite with our changes.

Yeah, we would be happy to host your code in our git repository on
sip-router, I think that this is a good idea, having all the stuff
available through git would make it much easier to integrate stuff.

First of all I suggest that we start by importing the whole openims
svn tree into a standalone project in our git repository. We can setup
scripts that will track the svn tree for a while and import any
changes done by your developers there until you announce that the
project migrated. Having the whole SVN repository imported this way
would allow us to merge selected parts (i.e. openims modules) into the
main repository with full history. That would be the first step. I
volunteer to set this up if you send me berlios usernames, full names
and email addresses (needed to convert svn commit usernames to git
commit logs with full names and emails) of all developers.

After that we can decide how to integrate it with sip-router. Let me
just enumerate all the options that come to my mind:
  1) We keep openims as a standalone project within our git repository
  2) We import all the patches and extra modules on a separate branch
within the main
     repository.
  3) We add all extra openims modules into to the master branch into a
new module
     directory such as modules_o and commit patches that those modules needs.
  4) We drop new openims modules into the directory modules and
integrate patches.

I think that there is no single best option, what would work best
depends on the nature of the changes that we need to do to existing
code (i.e. patches to sip-router core and modules) and also on your
long term goals with the openims project.

Option 1) would work well if you plan to keep openims as a standalone
project that draws code from sip-router. This option would give you
considerable freedom to do changes to the code (even extensive ones)
and yet remain synchronized with the main sip-router tree. We would
setup a new project for openims in our git repository and set it up in
such a way that it becomes easy to pull changes from the sip-router
repository into the openims repository. Whenever you have something
that is ready to be integrated into the main sip-router tree, you
could simply let us know that there is something we should pull and
once we do, the change would eventually propagate from sip-router to
openims next time you pull. Git makes this mode of operation
relatively painless, this is also roughly the model that the Linux
kernel uses.

Option 2) would give you the same amount of freedom as 1), but it
would probably be difficult to maintain a large number of changes on a
separate branch for extended periods of time (my own experience). In
my opinion this would only be suitable if the long term goal is to
fully integrate openims with sip-router, but we are unsure how long it
will take to integrate all necessary changes and patches.

Option 3) (a new module directory), I am not sure whether we really
need to put openims modules into a separate module directory. Having
two module directories is a temporary measure because we have two
versions of most modules, but our long term goal was to migrate them
where possible. I suppose that all openims modules are new, so we can
either put them in "modules" directory right away, or in "modules_s"
or "modules_k", depending on which version of existing modules their
require.

Option 3) and 4) are suitable if your long term goals is to merge
openims modules into sip-router and make them part of the sip-router
project. Note that this means that openims developers would have to
follow the sip-router way o development (releases, testing, code
integration), no matter how bad or good it is :-).

I would personally favor 1) if you want to continue on your own or 4)
if you want to integrate your stuff with sip-router, but let's see
what other have to say. In any case we can start with importing svn
into git, that's something we will need anyway.

   Jan.