My interest is mostly in writing new Modules for OpenSER at this time. I could not find a lot of information about it, so I started this page set. Please if you find I am going down the wrong path, correct me and these pages. I will try to only include correct information, but I am learning as I go.
The code and APIs are based off the current 1.1.x source base.
* Script commands we export.
* value if it is a special process calling the child init function.
You must include the MODULE_VERSION macro. This tells OpenSER the module was built for the correct version of the running OpenSER when the module is loaded. If the version number does not match, the load will fail.
Declare your local initialization and destructor functions.
Fill out the following data structures to export the modules functionality.
stat_export_t If your module wants to track statistics this is where you declare and export them.
module_exports - This is where you tie all the exported information together to define your new Module.
The module name. A char * that uniquely identifies your module.
Need more information on this function pointer.
You should be able to cut and paste the code above into your first module "C" file. To build the module, read the Module Makefile section.
name char * - A null terminated command name.
function int (*cmd_function)(struct sip_msg*, char*, char*) - The C function pointer to bind to the named script function.
fixup int (*fixup_function)(void * * param, int param_no); - Need more information on this function.
REQUEST_ROUTE - The function can be called in the request route section of the openser.cfg script.
FAILURE_ROUTE - The function can be called in the failure route section of the openser.cfg script.
ONREPLY_ROUTE - The function can be called in the reply route section of the openser.cfg script.
BRANCH_ROUTE - The function can be called in the branch route section of the openser.cfg script.
Because the module is written in "C" you must be carefull about naming your functions. The function field in the cmd_export_t structure can be file scope (static) if you want to define the real handler in the same file as you define the cmd_export_t structure. In most cases you will want to define all your handlers in a separate file like MyMod_handlers.c. In this case, make sure you add your module name to the begining of the function named to ensure there is no namespace collisions. i.e. MyMod_func1().
dishes, and pet fish – is not the main focus of openSER, and although your module plugs into the openSER framework, it could just as well plug into some other framework instead of openSER.
The GPL would not force distribution of your trade secrets involved in your dog/dish/fish component.
Addition of a module does not constitute a modification of openSER, nor does selection of openSER as a product's framework for interfacing with VOIP necessarily make the resulting composite work a derivative work of openSER.
Said home automation system would not be "based on" openSER. Said home automation system would include openSER for VOIP functionality.
Adherence to the provided and documented module API fulfills the "arm's length" requirement discussed at http://www.gnu.org/licenses/gpl-faq.html#TOCGPLInProprietarySystem even though the module and the framework will be linked into a single binary executable file, which is a technical detail.