This can be used with sipcapture and begings with M2UA and ISUP support. More SIGTRAN (M3UA, SUA) support is planned and maybe TCAP/MAP in the future.
The ISUP message format depends on the specific message so I have exported a Smalltalk ITU ISUP model to C to avoid manual errors. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/837
-- Commit Summary --
* ss7: Introduce the beginning of a ss7 module
-- File Changes --
A modules/ss7/Makefile (19) A modules/ss7/README (57) A modules/ss7/isup_generated.c (467) A modules/ss7/isup_generated.h (130) A modules/ss7/isup_parsed.c (485) A modules/ss7/isup_parsed.h (37) A modules/ss7/ss7.c (348)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/837.patch https://github.com/kamailio/kamailio/pull/837.diff
should we keep this module's name or change to another ?
sipcapture is using the HEPv3 protocol and it can encapsulate non SIP payloads (e.g. M2UA+MTP+ISUP). This is a first implementation/try and only supports M2UA/ITU MTP/ITU ISUP. ISUP is converted from the wire message to a semi-parsed (some fields are extracted but not all) JSON object and then converted to a string. A parameter exists to get the string representation from C into the kamailio script.
@adubovikov
@miconda any suggestion ?
Trying to understand what's the module about in order to be able to make more comments on its name:
* does it receive ss7 packet over hep3 or it can forward it to homer over hep3? In Kamailio we can also receive binary packets which are not sip (we do for stun module) * what is the target in long term for the module? In other words, what it tries to achieve from the point of view of sip and ss7 worlds? E.g., routing ss7 or just analyzing them?
* It receives M2UA over hep3 (through the sipcapture module) * Right now it is just meant to parse ISUP (and later TCAP/MAP) and store it in the home/sipcapture db.
The module will be able to parse ISUP binary protocol to string serialization i.e. JSON or pseudo variables and later we can insert the parsed messages into DB and using it in Homer.
Then maybe ss7ops is more appropriate as name, not to suggest a protocol support.
Will rename and right now wait for more feedback.
Some remarks:
* there are several places where I spotted 'sipcapture' as module name * each .c and .h file must have at a top the license text and copyright line * the documentation has to be written in xml docbook format, stored inside the doc/ subfolder of the module directory (like the other modules)
* Did the rename locally * Will write docbook * For license text/copyright. The ISUP table is generated and I don't think it can be copyrighted (the information is to match ITU ISUP, no creative process involved). What license text should be there?
Ohh, I missed the fact those file were generated -- it is ok to leave them without a copyright header if the generator doesn't insert one.
Okay, renamed directory and module name to ss7ops, instead of handwriting the README (I wondered why one would do that) added a minimal docbook (based on the sipcapture one).
Seems like "ss7capture" would be a better name if I understand this correctly. I would like to use the name to relate it to sipcapture.
disagree, because we can use the module not only for "capturing scenarios", but hypothetically also for interworking and/or SIP-I/SIP-T.
Ok, I see. Then I'm ok with the name :-)
don't forget also about IMS and MAP/TAP, CAMEL... this is also a huge area for ISUP
Then we need to clarify the relationship to the existing SIPT module.
unfortunately existing SIP-I module has very limited functionality and couldn't be use here.
In my opinion that's fine as long as we know that these are not built to work together. We have multiple modules overlapping since before.
Merged #837.
Thanks for the new module, merged!
@zecke - I got some warnings when compiling the module, so I pushed some fixes. Check the commit e0d26f780ed551bd993ca36ac125e87a16db7709 - it seemed wrong initialization of the same index, I guessed it should be the next, but it might not be the right.
@zecke - can you also add basic examples of using the params and functions in the docbook xml. You can see in other modules, like:
* https://github.com/kamailio/kamailio/blob/master/modules/async/doc/async_adm...
Thank you. 53 is indeed the right value for the UPA message.I will look into more/better documentation.