Support for one-to-many type SCTP sockets

[abhayani]

Most client SCTP associations share the same local port number so the Mobicents SCTP implementation has to be extended to be able to use one-to-many type SCTP sockets.

The New implementation package

We decided to create a separate implementation package because for the following reasons:

· The semantics of the one-to-one and the one-to-many type SCTP sockets are quite different.

· We decided not to implement the whole functionality of the SCTP API:

o Our target infrastructure does not use server type SCTP association by design so it is decided that the new implementation won’t support server type associations (note: it was more like an “economical decision” and is quite possible that we will also implement server functionality in the future).

o supporting TCP connections is out of scope of our interest

The new SCTP API implementation package is named to org.mobicents.protocol.sctp.multiclient.

Init process of one-to-many SCTP connections

The init procedure of the one-to-one and one-to-many like SCTP sockets (channels) are different. The main difference is that there is no connect operation for SctpMultiChannel. Associations of an SctpMultiChannel is initialized by sending the first DATA message. The lack of connect operation poses the following problems:

· Some features of the API depends on connect operation. For example when a link is going down a reconnect sequence is started in order to bring back the association automatically as soon as possible.

· In the our target environment where JSs7 stack is used on the top of the SCTP layer higher level layers do not send any payload through an association until the association notifies its listeners that it is connected.

· In our development it is a very important directive no to change the existing SCTP API which could not be avoided if the initiation processes of the two type of SCTP channel are different

As a solution for this particular problem a special connect method is implemented for the One-to-many like associations. In this method the association send a „dummy” DATA message to the remote peer which implies the correct association initialization on SCTP level. By default the dummy message is an empty DATA chunk, but it can be set using the setInitPayloadData(…) method of MultiManagementImpl class.

SCTP configuration persistence

The Mobicents SCTP and JSs7 libraries have their own solutions for persisting their configurations. This feature of the libraries is undesirable in our target environment, because our system has its own solution for configuration management which makes this feature redundant. Therefore a new Boolean type system property switch: “ss7.disableDefaultConfigPersistance” is introduced. Setting this property value to “true” the configuration persistence feature of the SCTP library can be switched off.

Association branching

SCTP multiclient package provides two type of association. These are the branched (or one-to-one) and the not-branched (or one-to-many) type associations. Branching means that the association is peeled off the multichannel socket to a separate socketChannel which is backed by a separate fd on kernel level. The new channel and the multichannel will share the same selector and selector thread. The advantage off this branched mode that the one-to-one association can be managed separately from the other association. It can be stopped and started on SCTP level (sending SHUTDOWN and INIT messages). While on SCTP level one-to-many association can shutdown only altogether by closing the multiSocketChannel (which handles all one-to-many associations of a same local ip- port address).

The branching feature is controlled at stack level not per association basis, so it is more like an operational mode of the stack. In branching mode all one-to-many like associations are peeled off to a separate one-to-one like association after the association is initialized, while in non-branching mode no association is ever branched.

By default multiclient SCTP stack is in branching mode, but it can be modified by a new Boolean type system property: “sctp.enableBranching”.

These are the main features and limitations of our line of work on this library.

I’d like to ask you to consider if our work described above (in any form) is worth to be “pulled” in the original Mobicents SCTP project. If you need more details please contact me.

Thank you for your time.

Best Regards,

Gábor

[vetss]

Hello Gábor,

thank you for your update.

I am checking your pull request and thinking how can we accept it. We are preparing new SCTP releases now. Please let me know if you are still interested in including for your update.

1. can you please describe how are you going to use one-to-many type SCTP sockets and for which cases. Do you mean that you use SS7 stack applications on top of it ? If yes - what is the advantage / use case of one-to-many type SCTP sockets. May be some equipment or network topology just needs it. If you refer me some guide it will be the best.

2. SCTP project now starts of usage netty and tries to introduce congestion control, may be you can check how we reuse it (code is now in master branch) and think if you need / is interested it too.

3. We need that the style of SCTP project. We do not use now System.getProperty() at all. We can think of introducing of some stack level parameter like "boolean disableConfigPersistance" that is false by default and can be configured by some setter like:
   public boolean setDisableConfigPersistance(boolean value);
   and if it is set before the stack is starting the stack will not load / store parameters.