Pull request for issue #10: Support to one-to-many type SCTP sockets

[AlerantAppNGIN]

The modifications consists the new multiclient package and the disable configuration persistence feature as desctibed in issue #10.
Please, comment and ask me if you have any questions.
Thank you,
Gábor

[deruelle]

@AlerantAppNGIN it looks like there is a lot of changes in this and it has conflicts with the master. Can you rebase your work ? Did you try with the new netty based master ?

[AlerantAppNGIN]

Hi @deruelle,
I’ll have to examine the new netty based SCTP implementation but if I understand it right it doesn't support one-to-many type client associations either so our modifications would still provide new functionality.

Please note that our "multiclient" SCTP implementation isn't a complete implementation of the Restcomm SCTP API: it only supports client type "SCTP" associations.
I also have to mention that our solution has a drawback by design. To work around the difference in the session establishment flow of one-to-one and one-to-many type associations, the stack sends an SCTP DATA message with configurable dummy content to establish the SCTP connection. This worked well in our production environment, but it might not be a generally acceptable solution.
For these reasons I think that our multiclient solution should exists as a separate, alternative implementation of the Restcomm SCTP API.

To answer your question, we are planning on creating a new netty based version of our work, but you should consider how you want to list these solutions (netty and non-netty based multiclient implementations) in your repository. We are also open to modify our work to be a complete SCTP implementation, ideas on how to achieve this goal are welcome, particularly regarding the session initiation procedure.

Regards,
Gabor Balogh as @AlerantAppNGIN

[deruelle]

Ok I'll let @vetss comment on what makes most sense here and if it makes sense to merge it in the non-netty branch.

A more complete SCTP implementation based on netty is certainly a good idea. @vetss can drive this discussion as well.

[vetss]

Hello @AlerantAppNGIN @deruelle

but if I understand it right it doesn't support one-to-many type client associations
either so our modifications would still provide new functionality.

you are right no of SCTP version supports one-to-many type associations.

I have revised again your update. The core of our SCTP project implementation is org.mobicents.protocols.api.Management interface that contains staff for managing SCTP servers / associations (adding / deleting / specifing of parameters and persisting of current config set). Under this we have some classes that provide concrete functionality. As for now we have two implementing of Management interface:

• "old" nio - org.mobicents.protocols.sctp.ManagementImpl
• "new" netty - org.mobicents.protocols.sctp.netty.NettySctpManagementImpl

Your update does not touch Management interface (so you do not provide any possibility to have management of new staff via Management interface). This is some design disadvantage.

You provide only disabling of persisting functionality into Management interface. We can accept this.

For these reasons I think that our multiclient solution should exists as a separate, alternative implementation of the Restcomm SCTP API.

It is desirable to have a management solution for one-to-many type associations via Management interface to have a single and clear design for a whole project. If you need we can discuss it.

What can I do:

• most of your work is a new staff, new files. To avoid a work for merging conflicts I can just add new files into a master branch (if you point me a repo/branch with actiual files version)
• I can also add an option for disabling of config persistion

[AlerantAppNGIN]

Hello @vetss,

Thank you for the review.
I like the idea to modify the Management interface. I think we should discuss it before we add any new code to the repo.
I'll start working on this issue in a week, I'll contact you soon.

Regards,
Gabor

[vetss]

Thanks @AlerantAppNGIN for update.