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

Hi Daniel, On Thu, Jul 23, 2009 at 9:00 PM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: quite a bunch of work, I would say. Can cdp be used for generic diameter AAA or is specific for ims? No, the CDiameterPeer module is not specific and it can be used for anything that talks Diameter. The only IMS specific parts are a bunch of constants defined for the IMS interfaces in a header file, but of course there is space for other applications, which are of course welcome to it. The cdp is a bit of a "server" itself that is forked from ser and can benefit from all the advantages that a ser process has. But it has it's own timer, workers, etc processes. The advantage of this is that it is quite easy (and we actually do provide an example here: http://svn.berlios.de/wsvn/openimscore/CDiameterPeer/trunk/#_CDiameterPeer_… ) to get a standalone Diameter node on the same platform. This is useful for implementing the other ends of the AAA communication when you like the ser memory, locking, etc routines ;-) but don't need the SIP related stuff. I have quite a high confidence in the stability of this module as we seldomly had issues with it. On the things to improve would be though: * replace the sempahores with something better - they tend to accumulate over crashes of ser * merge a branch that adds support for the authentication state machine and add the charging state machine - although I don't know if anyone would actually use this part and it would maybe just be overkill. IIRC, openser imported the ratelimit from openimscore, can you check if includes the features you have? http://sip-router.org/docbook/sip-router/branch/master/modules_k/ratelimit/… Right, now I remember. So then one less thing to worry about. Sorry, I was only monitoring the ser tree. * Core - support for emergency URI, What is this exactly? Any reference to ietf/itu specs? I am not really sure myself as somebody else did the implementation. But all the specs should be listed here: http://www.openimscore.org/emergency . And even for us this is still partly a branch with work in progress. The thing was that ser was even crashing when it got some of these, so in any case, even if not used, it would be a good patch. I'll have to do a diff and find out what was exactly changes as there were to many things in the last 3-4 years. And we probably have some garbage through that. I'll send the patch after some cleanup. - sip-router_modules_s_dialog.diff - just some typos in logging This can be applied right away. I do not know who is in charge of the SER dialog module, if no one volunteers for it and you want to jump in, send me your ssh key and desired uername for git account. Will do shortly. Will still have to get up to speed with git before pushing anything though. - 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. I am not yet familiar with the new way SER manages the process table. Andrei, Jan or other ser developer may have more insights and guide here. Partly the new process table management was sparked also by me, from the same requirements as now. Unfortunately for the first part not all of my patch made it and the other part was actually greatly improved by Andrei. If the case is that it won't be accepted that a process can dynamically terminate, then I'll have to redesign cdp. It's not a huge deal, but I'd rather not as it will just complicate things and I think that the process drop is not such a big deal anyway. For the 2nd part, this was added later and I'm not sure if I did something wrong and the fork should've been done differently. But it looks like a potential bug anyway. I was looking to build such summary for kamailio, since current version is hard to track and creates quite big logs, which slows down the shut down. Can you create a new patch against sip-router core and attach to tracker: http://sip-router.org/tracker/ Will do. I also added to our ser_ims some clean-up code that frees-up a lot of the core's memory on shutdown. Unfortunately I got stuck at the fixed parameters, which you can't really make sense of in the core in order to free them. So I guess there's need for some "unfix" functions in the modules. Cheers, -Dragos -- Best Regards, Dragos Vingarzan