It depends on what would you like to contribute with:

• If it is knowledge, feel free to immediately use the mailing-lists and share your ideas with the community.
• If you have something important to share, please ask for a editor-account on this website and start writing!
• If it is bug-fixing code, just post it on the mailing-lists and it would be checked and applied ASAP.
• If you want to contribute a bigger code chunk, like a new feature, just ask for a branch on any of our projects and do your part without having to check with a senior developer. When you think that you are done, we will merge your work into the main project tree (giving that you do not break other people's contributions or that you have a way of completely disabling the feature, from configuration, in case you do).
• If it is a whole new sub-project, be prepared to actively support it for at least a reasonable period of time, because having components that barely work and are not supported by anybody is just making us loose focus.
• For anything else, just contact us.

First of all you would need an up-to-date revision of the Open IMS Core. So before you begin, upgrade to the latest revision in the SVN (IPv6 was introduced around r529, but you should always update to the latest revision that contains all the bug fixes).

Then you need to change your DNS and configuration files to make use of IPv6. For DNS, if you would like to have a FQDN (domain name) translated to an IPv6 address instead of an IPv4 one, use an AAAA entry instead of an A one:

pcscf4 1D IN A 127.0.0.1
pcscf6 1D IN AAAA ::1


The C/JavaDiameterPeer configurations are trivial to change as you just need to modify the bind parameter to an IPv6 address. No bind parameter will result in the Diameter stack listening on all available IPv4 and IPv6 interfaces.

The CSCF configuration files are also trivial to change as you only need to modify the listen parameter to the IPv6 address that you require. Also make sure that if you enable only IPv6, you also change the hard-coded loop-to-myself addresses from "127.0.0.1" to "::1".

Although many IPv4 functions do not make sense for IPv6 (e.g. NAT relay, Early-IMS authentication), they should technically work with IPv6.

If you discover any issue, as always, please write us on the mailing-lists first. Don't fill a bug-report immediately, but let us first acknowledge that it is a bug and one that was not already been filled.

Yes. In case your svn checkout should not work, you can download the appropriate project from our ftp site:
ftp://ftp.berlios.de/pub/openimscore/snapshots/

You really need a DNS server. For example the P-CSCF will do a NAPTR/SRV query to find the I-CSCF and only a true DNS server will be able to solve this. If you need help with that, please read this.

This is a specialized piece of software and we are always prioritizing state-of-the-art features over making it easier for unexperienced users to deal with it. Anyway, if you got here it means that you are too, for now, looking at future network technologies and should be familiar with the concepts and specs. If you are not, we recommend that you first attend a few tutorials on IMS, Linux administration and C/Java programming; or you could hire somebody (from our community for example) to do the job for you.

It might be that in the future the networks would be so distributed that having IMS cores would be a commodity. But for now, they are not and we can not justify the resources spent on building nice GUIs when there are so many more important open issues.

That is not to say that we would reject you if you would like to invest your resources in making the Open IMS Core more user-friendly. We will always welcome anybody willing to contribute towards making the project better.

Most importantly: DO NOT FILL A BUG REPORT IMMEDIATELY!
Second most importantly: DO NOT EVEN THINK ABOUT POSTING SUPPORT REQUESTS IN THE ISSUE TRACKER! The request will be closed. Use the issue tracker only for outstanding bugs that have been discussed and accepted. Think that you might have just mis configured something and you will get your answer quicker and easier by asking on the appropriate mailing-lists.

When in trouble, you should, in this order:
1. Always read the FAQ. There is big probability that you did something wrong and the answer might be just there.
2. Search the Mailing List archives.
3. Use the documentation if possible.
4. Ask on the mailing list.
5. If the community acknowledges the bug/feature-request, post a detailed issue in the Support section.
6. If you found an answer please contribute it back so that others might find it easier. This is an Open Source project and you can only benefit the most when you contribute.

It might take a while until you get an answer as our resources are not unlimited. When you feel that it takes too long, post a reminder. We don't mind you being pushy if you do understand the Open Source model. But we do mind if you don't and you think that we MUST provide you with a satisfying answer.

It might also be that the answer won't satisfy you. In any case, you are most welcomed to contributed in any way that you see fit to the project - code development, website editing, resources, etc.

The target of the whole project is experimental. As such, we love logging because we want to know what happens. The CSCFs might print a lot of those. You can, of course, at any time change the logging level from the configuration file (the debug parameter).

Unless you can tell that there is a bad behavior, don't bother reporting them as errors. On new features we like to print a lot of information colored like crazy even if they are not errors. It helps us notice if the new code functions correctly and also it makes you aware that there is something new ;-). In a few weeks/months these logs would no longer show as they will be demoted to lower importance.

The most important thing to remember is that they should all be prefixed based on the importance, like DBG, INFO, ERR, etc and this prefix overrides the actual colors and log levels.

Are you sure that you have changed all the configuration files? Grep for the old domain name.

Have you changed the s_cscf table in the icscf database? It contains the list of all your S-CSCFs.

Check the imsu table in the hss_db database. It might be that you have IMS Subscriptions that were left as registered in the old S-CSCFs and now the HSS/I-CSCF are trying to redirect you there. Clear the values in there.

You have probably forgot to add privileges for the user, that you are trying to register with, to perform authentication with the algorithm of your choice. In most cases you switched the authentication method in the S-CSCF but you did not allow the user to use anything else than AKAv1-MD5.

This error might also indicate that you are trying to use an authentication scheme not supported by the HSS in use. Please check that the authentication scheme is supported.

Obviously you need to fill in the SIP URI of the Application Server. You can use of course parameters, ports, etc.

Then you need to specify what should the S-CSCF do if this Application Server fails to respond to messages. You can indicate that you want the sessions to be terminated or continued based on how critical is your Application Server in your system.

Because almost any SIP server/proxy/user-agent can act as an Application Servers and they can be trusted, semi-trusted or completely untrusted, you need to also configure what is that Application Server allowed to do when communicating directly with the HSS, on the Sh interface.

Only because you have configured an AS in the HSS, it does not mean that signaling will be redirected towards it. You need to:
- attach this Application Server to one or more Initial Filter Criteria (which contain the message matching rules in the Trigger Points),
- then add the Initial Filter Criteria to a Service Profile,
- then make sure that your users have the right Service Profiles attached.

A Service Profile is a group of Initial Filter Criteria, each with an attached priority. Each user can have such a Service Profile attached and this is downloaded from the HSS to the S-CSCF on initial registration, profile changes or when there is a message towards a user that has a Service Profile containing at least an Initial Filter Criteria applicable for the terminating towards unregistered user case.

The Initial Filter Criteria will be evaluated for each initial request in the priority order. On a match, the request is forwarded to the respective Application Server. If the Application Server responds with a final response, that response is relayed back and the matching session is terminated. If the Application Server responds with a modified request (proxy mode), the matching session is resumed. When the matching session ends the message will be forwarded further.

No, there is no such thing. Subsequent requests can not be filtered or forwarded towards Application Servers.

If you have an Application Server that needs to receive subsequent requests (like a Online-Charging-Proxy), then you should filter the initial request for that dialog and have the Application Server Record-Route.

The Initial Filter Criteria is the grouping between a Trigger Point (the logical expression matching a message) and an Application Server. The absence of a Trigger Point in an Initial Filter Criteria indicates that the message should always be forwarded to the respective Application Server.

The Initial Filter Criteria can only match Initial Requests, like INVITE, REGISTER, SUBSCRIBE, MESSAGE, etc. Subsequent messages (like BYE, NOTIFY, INVITE inside a dialog, etc) are not checked or forwarded.

Each Initial Filter Criteria can be set to match only when the respective user on which it is set is registered or unregistered or in both cases.

A Trigger Point is a logical expression of Service Point Triggers. It is composed of groups and each group is formed of the logical atoms, the SPT. It can be of 2 types, based on what logical condition is applied inside the groups and between them:

1. Conjunctive Normal Format (CNF) - (A or B) and (C) and (D or E or F)
2. Disjunctive Normal Forma (DNF) - (A and B) or (C) or (D and E and F)

The Trigger Point is used to build complex message matching conditions.

The Service-Point-Trigger is the smallest logical atom in the Trigger Point. There are 5 distinct types of SPTs, based on what each of them is used to check in the SIP message:

1. Request-URI equals <value>
2. SIP Method equals <value>
3. SIP Header matches <regular expression>
4. Session Case is one of [originating, terminating, terminating to unregistered user]
5. SDP Line [<line name>] matches <regular expression>

The result of each SPT can be negated, as required. Also it could be specified to each SPT if it applies to the Initial/Re/De-Registration when checking a REGISTER message for triggering a 3rd Party Registration.

The SIP Header SPT can be used to also test the absence of a header by negating it and omitting the regular expression.

You can always use the FHoSS web interface running accesible http://localhost:8080 on the FHoSS machine (this web-interface is part of the HSS, so you need to run the HSS in order to access it).
For automating this process, you can also use the add-imscore-user.sh script found in the ser_ims/cfg/. Look inside for usage instructions.

berliOS uses a template for indicating the SVN URLs. As we have more than 1 sub-project, please use the links indicated here.

In order to keep a high quality for the code, only a limited number of maintainers have modification permissions. Each is responsible for checking if new patches work properly and for the administration of the sub-projects. Please post your patches to the mailing-lists and they will be checked and applied. If you are an active contributor and you demonstrate that your patches can be trusted, we will add you as a project maintainer.

Then you will get this access sooner. You will just have to convince one of the maintainers that your branch makes sense. While working on branches you can be more relaxed regarding commits as you don't have to make sure each time that your modifications do not break something.

We know of one download link that lets you get your hands on a free 2 port evaluation version of a MRF which should be enough to show simple scenarios involving e.g. IVR. If you are not looking for an open source solution and are not afraid to tell the sales folks at Cantata all about yourself, see this link for details on licensing etc.

Take a look at the pcscf.cfg and scscf.cfg - there you can find the example for the new persistency setting in (per default) commented blocks. To enable e.g. file storage in the S-CSCF use:
modparam("scscf","persistency_mode",1)

Also do not forget to create the directory path that you configured or to create the database structure in case you selected the database storage.

There is no specific tutorial but the addition of a new application server can be done in few steps using the FHoSS web interface:

1. Create the application server entry, assign the routable SIP address for that application server. The choice for “Default handling” indicates to the S-CSCF what should be done with the SIP session in case that the SIP AS address is not reachable.
2. Define a trigger point that matches the criteria to trigger one of the applications on the app server
3. link the application server to the trigger point by creating a new intial Filter Criteria (iFC)
4. add the iFC to the service profile of the applicable users (e.g. the "default_sp")
5. make sure that the service profile is assigned to the users public identity in the user profile section and prioritize their handling in the S-CSCF (0 has the highest priority)

Depanding on the incoming message descriptions given in the trigger point defintion you have many options to trigger specific AS addresses via certain iFC definitions for almost any scenario. Per default, we just provide one service profile with a simple iFC for an imagined presence server.

The usual problem that occurs when the additional resources are generated, through ant gen, without a current Intenet connection is:
Error reading import file 'http://www.w3.org/2001/xml.xsd': java.net.NoRouteToHostException: No route to host.
This occurs because the source generator tries to import the specified file from the remote address. The solution is:

• Download the xml.xsd from here and copy it on your machine, for example in xsd/ folder of FHoSS
• Edit the file xsd/ZhDataType.xsd and change the path "http://www.w3.org/2001/xml.xsd" to your local path; for example "file:///opt/OpenIMSCore/FHoSS/xsd/xml.xsd"
  E.g. Original file:
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
  Modified file:
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="file:///opt/OpenIMSCore/FHoSS/xsd/xml.xsd"/>
• Run again
  ant gen
  and now it will work.

Some steps are necessary in order to do that:

• first provision the users (or use the default sip:alice@open-ims.test or sip:bob@open-ims.test). Make sure than in the HSS provisioning interface in the IM Private Identity configuration, you allow the use of Digest-MD5 for the respective users.
• modify the scscf.cfg and enable the MD5 authorization as the default authentication method instead of AKAv1-MD5.
• Next just make sure that the client is using the P-CSCF address (sip:pcscf.open-ims.test:4060 by default) as strict outbound proxy and the REGISTER Request-URI is "sip:open-ims.test" (or your own domain name) and not "sip:pcscf.open-ims.test:4060" as many SIP clients fail here.

The Open IMS Core has support for MD5 authentication. Also, you can use SIPp, which has support even for AKA and media

There are several IMS clients out there recently, which can be used with the Open IMS Core.

• FOKUS' OpenIC (Open IMS Client) is available only commercially (Contact: info@open-ims.org). Yet, there is also a free binary OpenIC_Lite version available right here
• The UCT IMS Client which is available under the GPL
• The IMS Communicator, also under the GPL