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

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 ------------------------------------------------------------------------ _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev