Adding correlation_id as parameter in transport_hep

[jmontorosf]

In some cases it would be interesting to add '' in transport_hep.xml in order to correlate the captured traffic from different sources.

[CLAassistant]

All committers have signed the CLA.

[lmangani]

Hello @jmontorosf and thanks for your PR! Could you explain the scenario for this change and what is the goal of this change?

[jmontorosf]

@lmangani thanks for your reply,

The scenario would be caller->b2bua1->b2bua2->callee

In this case we can currently send to homer and see the generated traffic by caller and the traffic received by the callee, and we introduce parameters (correlation_id) in either end to identify both legs that let us display accordingly. However if we want to see the traffic between b2bua1 and b2bua2 we need to sniff it passively there. And for that reason we decided to go with captagent/heplify. But they dont offer the possibility to force such correlation by default.

I can understand enabling the correlation_id by default in a general setup wouldn't make much sense as it would show every call/leg to be part of a endless call. But in a controlled scenario for testing and in order to see what's going there it would be benefitial to see calls flow through different network elements without having to look for them manually.

Let me know if that makes more sense now.

[kYroL01]

Hi @jmontorosf Thanks for the PR - let me review it and let you know :)

[kYroL01]

@jmontorosf I think the PR is valid, but we need to add the variable in transport_hep.xml @lmangani anything to object to the explanation he gave us for his goal ?

[jmontorosf]

@kYroL01 for some reason it got skipped in my original comment but it would be something like this:

<param name="correlation-id" value="mycorrelation_id"/>

do you want me to add it in the file and commit it myself?

[adubovikov]

@jmontorosf thank you so much for your patch, but IMHO this is a wrong way. The correlation_id is a dynamic variable which have to be injected base on a current session (SIP, RTP, Diameter) and you couldn't make it static. In your scenario, that you can do, just add X-CID on each B2B instance and make multicorrelation in the correlation mapping.

Your scenario: caller->b2bua1->b2bua2->callee

A party -> B -> C -> D party

SIP on B - has X-CID: callid_of_A SIP on C - has X-CID: callid_of_B

Correlations steps -> C -(X-CID) of B -> (X-CID) -> A

Regards, Alexandr

[jmontorosf]

@adubovikov agreed, I've been working with HOMER in the past and that was the way to go, adding a X-CID header... For this case in particular, what if we do not have access to the B or C configs to add that extra header but we can run captagent (with a dynamic correlation_id) on demand?

[agranig]

Hey 👋 we do have scenarios where captagent is started for the duration of a couple of calls, and we want to capture all messages during that time window and have them be found under a single correlation id. In that case, we don’t have the sip messages under our control, as they could be registrations of a pbx and then calls and presence messages of phones behind that pbx, and all of them belong together.

If not using a static correlation id, how else would you approach that?

[adubovikov]

@adubovikov agreed, I've been working with HOMER in the past and that was the way to go, adding a X-CID header... For this case in particular, what if we do not have access to the B or C configs to add that extra header but we can run captagent (with a dynamic correlation_id) on demand?

And what it will do ? You will have always same correlation_id for all SIP sessions... I don't understand the case.

[adubovikov]

Hey 👋 we do have scenarios where captagent is started for the duration of a couple of calls, and we want to capture all messages during that time window and have them be found under a single correlation id. In that case, we don’t have the sip messages under our control, as they could be registrations of a pbx and then calls and presence messages of phones behind that pbx, and all of them belong together.

If not using a static correlation id, how else would you approach that?

oh oh, you wanna use BULK correlation, but isn't easy to set dynamic capture_id and do lookup ? :-)

[lmangani]

This approach would indeed be an anti-pattern since correlation_id was never meant to be controlled by the config or hardcoded and should be controlled by the agents, which are designed to fill this in dynamically.

Hack for hack, here's a more flexible approach which requires no code changes:

• switch to heplify and heplify-server
• in heplify set a unique node_name for your custom session (ie: abc123) and a special node_id (0000)
• in heplify-server write a lua script to swap node_name into correlation_id when node_id equals 0000
• enjoy

[jmontorosf]

Thanks for the commends @adubovikov and @lmangani, we'll try using heplify with the proposed approach, correlating the captureId from heplify with the correlation_id.

[lmangani]

@jmontorosf let us know - remember to use node_name as string and node_id as int trigger/vector for best results