2008-11-20
- photos and minutes from Karlsruhe SIP Router meeting published...

Photos taken during the meeting day are available at:

http://sip-router.org/pub/photos/album-sip-router-karlsruhe/

Meeting minutes:

• development side: move forward, sip-router.org source repository should be up next week
• end of January we should have a runable core+tm with support for the most used features from both Kamailio (OpenSER) and SIP Express Router (SER) (100% support might be a little delayed as some features may become obsolete)
• Kamailo next-next release (probably after spring next year) will be based on sip-router core+tm
• next or next-next SER release will be based on sip-router (SER might make another 2.1 release from the current CVS, since the code is ready - to be discussed)
• future releases will most likely be common and will unify all or most of the modules (depending on everything up to that point working ok)
• copyright: patches that are not accompanied by (c) claims will not add to the (c). We should put this on a web page and when in doubt we can ask the patch author for confirmation. While it’s likely this has no or very limited legalvalue (especially in Europe), it will server at least as a gentleman agreement. We need this because:

1. we need the agreement of all (c) holders for the GPL code to add licensing exemptions (e.g. we need to add an openssl linking exemption) and it’s easy if we have a known “small” set of (c) holders
2. people might not like having multiple (c) notices on files they created, just because someone did send a trivial or not so significant patch (note: “trivial” and “significant” are very relative). On problems, probably the board will decide, if nobody gives up the claim we’ll fork the module (worst case, to be avoided as hard as possible).

• forking modules: highly discouraged, but allowed
• unmaintained and rarely used modules: removed after a grace period
• board: for now we continue to have 2 boards, SER and Kamailo at least until we have something runable. In the meantime we should think/discuss how the common board will look like: how it will be elected and for how long, “composition” (how many devels, how many from the user community, testers a.s.o)
• testing: very important, Jerome proposed having beta-tester groups and stressed out the importance of dynamic tested. Everybody seems to agree, but there are doubts about finding beta-testers volunteers.
• release management: we need a release manager for each release
• documentation: Kamailio uses a wiki for core, and docbook .xml for modules, SER use NEWS (txt file) for core and docbook for modules, but it’s in the process of migrating to a more man page friendly format (still .xml). More discussion is needed, between the main doc writers from both sided.

sip-router.org:

• GIT repository should be up next week
• sr-dev mailing list should be used for technical dicussions related to merging the cores
• new features mails should be cc’ed to sr-dev too (very important especially when core or tm is involved).
• todo: find easy to remember short name

Related projects:

• some modules may be on separate repositories for a while (e.g., openimscore), maintained by their devs for using them out of the box with sip-router
• stand-alone application servers (Voztelecom/WeSIP, Iptego/SASI) may merge the communication interface specs in the future.
• it is a need for a place where to collect basic info about related projects

Further steps:

• new meeting, to be organized somewhere end of winter/beginning of spring 2009 (topics: celebrate first integrated working version, discuss further development of sip-router)
• setup of adjacent tools that help developing code and documentation (e.g., wiki, tracker)

General opinions:

• there are x-ser platforms running milions of users, sip-router must provide a rock-solid SIP server, esure trust and project reliability
• while having a strong focus on above item, innovation shall not be stopped, new features to be added as module to avoid effects to core and main modules
• very important modules (e.g., usrloc, registrar, …) should be protected as much as possible, patches and new features to be carefully reviewed not to affect stability and interoperability
• improvements to most important parts to be discussed on sr-dev mailing list