Proper logs for debugging of MSU flowing between different stacks

[abhayani]

As of today MSU flowing between upper layer like CAP/MAP to TCAP to SCCP to M3UA to SCTP is not identified by common identifier. Hence it becomes difficult to map log statements between different layer.

Probably all the message originated by jSS7 (transmitted message) must put TCAP LocalId in logs at all layers and all the received message should have unique identifier generated at SCTP that is carried all the way till TCAP (and MAP/CAP)

Amit.

[deruelle]

Adding @jaimecasero to the discussion as he did something similar at JAIN SIP level with CallID and log4J NDC/MDC

[jaimecasero]

Well, as shown in jainSIP example, this is better solved if we could introduce it at scheduling/dispatching (after IO, and before actual handling) level as a cross-cutting concern https://github.com/RestComm/jain-sip/blob/master/src/gov/nist/javax/sip/MDCScheduledTHExecutor.java#L110

Ideally, the tasks to be scheduled would provide the vars to be added as MDC. Thats why added an interface in JAINSIP case. https://github.com/RestComm/jain-sip/blob/master/src/gov/nist/javax/sip/MDCTask.java.

Since MDC vars are associated to the running Thread as threadLocals, its important to ensure the proper clearance of the MDC vars, once the activity has ended (otherwise those MDC vars will be printed for the next activity that thread run).

If you choose MDC vars, which seem to fit quite well on this scenario, It is also important to pick good names for the MDC vars, since that will be added to the log4j pattern (in recent versions there are expressions to print ALL vars), and prevent collision with third party libs...

[vetss]

@abhayani @jaimecasero

1. Thanks @abhayani for your work (patch)

I have processed provided by Amit patches and put it into the commit (it is not included into a master branch so far) : https://github.com/vetss/jss7/commit/262165b2899c35b86f2c63674c131ffad7247ace

Source files of Amit's patch is there: patch source files.zip

This patch just reuses TCAP dialogId as a general identifier and it covers of message sending part but it does not cover message recieving part. We may be need to update the algo by adding some extra (UUID ?) identifier for incoming messages that will be assigned already at SCTP stack. And then we can keep this parameter in TCAP stacks and display this as extra parameters for a dialog to cover all together.

@jaimecasero thanks for your update. We need need to think of your approach. The main problem so far is that architecture of stacks ("scheduling/dispatching" part) and methods step by step processing is different that you described. I agree that your approach has some advantages and we need to chenge somehow the logic.

I think we have to postpone this work till next release because it demands some more efforts and conceptual solutions and also debugging of this (not much time this turn).