Hi Daniel,
On Thu, Jul 23, 2009 at 9:00 PM, Daniel-Constantin Mierla
<[email protected] <mailto:[email protected]>> 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_trunk_
) 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/ratelimit.html
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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
