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

Thu Jul 23 21:00:39 CEST 2009

Hello Dragos,

On 23.07.2009 19:59 Uhr, Dragos Vingarzan 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.
>
> 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
quite a bunch of work, I would say. Can cdp be used for generic diameter 
AAA or is specific for ims?
>
> 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

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/ratelimit.html

>   * 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,

What is this exactly? Any reference to ietf/itu specs?

> 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 see no problem to include modules in the git, in a new directory, as 
you say below (maybe modules_i to follow the tradition :-)  : k - 
kamailio, s - ser, i - ims).

> 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
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.
> - 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.

>
> 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 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/

Thanks,
Daniel

>
> I am looking forward to your feedback on how to proceed and on the 
> attached patches.
>
>
> Cheers,
> -Dragos
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/