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

[Dragos Vingarzan]

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.

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
   * enum - support for query on the originating side, useful in PSTN
     inbound processing
   * 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
   * tls - some hashing functions
   * 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.

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.


Then I am attaching some small patches for now, with more to come in the 
next days as I will progress:

- sip-router_modules_s_dialog.diff - just some typos in logging
- sip-router_pt.diff
   - added a drop_my_process() function - in the cdp module (Diameter) 
we do have dynamic processes, which fork and exit distinctly from the 
ser ones, so we need this to clean-up. Without it, such usages would not 
be possible as the process table would fill and then new forks would be 
denied
   - I have commented the pt.c <mailbox:///root/private/_mail/Mail/common/Sent?number=587016624#pt.c> line 210. I am not sure if this is a bug 
or I just used the fork_process wrongly, but my process which was forked 
from a mod_init() not a mod_child_init() opens some sockets, which are 
mistakenly closed on fork_process() by the close_extra_socks(), which 
uses the pt[].unix_sock values from other processes, which overlap. So 
please advise on what would the best way be to still allow for the 
forked processes to open some sockets without them being closed on fork.

Both these patches are required in order to get the Diameter stack working.

Then there is this one that we use quite a lot for tracking memory 
leaks: http://tracker.iptel.org/browse/SER-224 . It's not there yet I 
guess, so should I resubmit it or forget about it?  ;-) 


I am looking forward to your feedback on how to proceed and on the 
attached patches.


Cheers,
-Dragos



-- 
Best Regards,
Dragos Vingarzan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip-router_modules_s_dialog.diff
Type: text/x-patch
Size: 641 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20090723/5155f04e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip-router_pt.diff
Type: text/x-patch
Size: 1621 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20090723/5155f04e/attachment-0001.bin>