Attempting a Mapping Rule for two SIP call legs

[jagnetta]

Good evening,

I'm attempting a correlation between two call legs on a custom header (sort of), here's what I'm doing:

A-Side: X-CC-TRACE: c=N36ADE4KASyKH7HjnbnNzQOQugCbC3Nc;a=Agent1@JimAgnetta2;i=int-18f35278ef1-cRcd2mBGwbwDJuURIfjrYX9PL-phone-00-JimAgnetta2

B-Side: X-CC-TRACE: c=out_806ae526-6774-482d-9bd4-228a2d398a68;i=int-18f35278ef1-cRcd2mBGwbwDJuURIfjrYX9PL-phone-00-JimAgnetta2

Everything after the "i=" field at the end is the same. So I'm trying this in my heplify-server.toml (which I've attached as well):
AlegIDs = ["X-CC-TRACE","i="?(.*?)(?:"|;|$)"]

And in mapping, under correlation I added this:
{
"source_field": "data_header.X-CC-TRACE",
"lookup_id": 1,
"lookup_profile": "call",
"append_sid": true,
"lookup_field": "data_header->>'X-CC-TRACE'",
"lookup_range": [
-300,
200
]
},

I'm hoping you can help me configure to read that part of the X-CC-TRACE header and make a mapping rule from it?

Thanks,
Jim Agnetta

[github-actions]

Your report is appreciated. Please star this repository to motivate its developers! ⭐

[jagnetta]

HEPAddr               = "8.25.198.130:9060"
HEPTCPAddr            = ""
HEPTLSAddr            = "0.0.0.0:9060"
HEPWSAddr             = "0.0.0.0:3000"
ESAddr                = ""
ESDiscovery           = true
LokiURL               = ""
LokiBulk              = 200
LokiTimer             = 4
LokiBuffer            = 100000
LokiHEPFilter         = [1,5,100]
LokiAllowOutOfOrder   = false
ForceHEPPayload       = []
PromAddr        = "0.0.0.0:9096"
PromTargetIP          = ""
PromTargetName        = ""
DBShema               = "homer7"
DBDriver              = "postgres"
DBAddr                = "localhost:5432"
DBUser          = "homer_user"
DBPass          = "nope"
DBDataTable           = "homer_data"
DBConfTable           = "homer_config"
DBBulk                = 200
DBTimer               = 4
DBBuffer              = 400000
DBWorker              = 8
DBRotate              = true
DBPartLog             = "2h"
DBPartSip             = "1h"
DBPartQos             = "6h"
DBDropDays            = 14
DBDropDaysCall        = 0
DBDropDaysRegister    = 0
DBDropDaysDefault     = 0
DBDropOnStart         = false
DBUsageProtection     = true
DBUsageScheme         = "percentage"
DBPercentageUsage     = "80%"
DBMaxSize             = "30MB"
Dedup                 = false
DiscardMethod         = []
AlegIDs               = ["X-CC-TRACE","i=\"?(.*?)(?:\"|;|$)"]
CustomHeader          = ["X-8x8-CCCI","X-8x8-CarrierList","X-8x8-BTN","X-GR_PLATFORM_ID","X-GR_TENANT_ID","X-8x8-Tenant","X-8x8-Channel","X-8x8-Original-Caller"]
SIPHeader             = []
LogDbg                = ""
LogLvl                = "info"
LogStd                = false
LogSys                = false
Config                = "./heplify-server.toml"
ConfigHTTPAddr        = ""

# Examples:
# -------------------------------------
# ESAddr          = "http://127.0.0.1:9200"
# DBShema         = "homer7"
# DBDriver        = "postgres"
# LokiURL         = "http://localhost:3100/api/prom/push"
# LokiHEPFilter   = [1,5,100]
# PromAddr        = "0.0.0.0:8899"
# PromTargetIP    = "10.1.2.111,10.1.2.4,10.1.2.5,10.1.2.6,10.12.44.222"
# PromTargetName  = "sbc_access,sbc_core,kamailio,asterisk,pstn_gateway"
# AlegIDs         = ["X-CID","P-Charging-Vector,icid-value=\"?(.*?)(?:\"|;|$)","X-BroadWorks-Correlation-Info"]
# DiscardMethod   = ["OPTIONS","NOTIFY"]
# CustomHeader    = ["X-CustomerIP","X-Billing"]
# SIPHeader       = ["callid","callid_aleg","method","ruri_user","ruri_domain","from_user","from_domain","from_tag","to_user","to_domain","to_tag","via","contact_user"]
# LogDbg          = "hep,sql,loki"
# LogLvl          = "warning"
# ConfigHTTPAddr  = "0.0.0.0:9876"
# -------------------------------------
# To hot reload PromTargetIP and PromTargetName run:
# killall -HUP heplify-server

[jagnetta]

I've realized that this line was wrong:
AlegIDs = ["X-CC-TRACE","i=\"?(.*?)(?:\"|;|$)"]
It is now:
AlegIDs = ["X-CC-TRACE,i=\"?(.*?)(?:\"|;|$)"]

In the image below, you can see that the A-Leg and B-Leg managed to populate the value I wanted to extract as the correlation ID, but they didn't correlate. I'm thinking there was > 5 seconds b/t the call legs, is this a timing issue? I must be close right?

[jagnetta]

I've been poking at it, but this is as far as I've been able to get. Here's the correlation mapping file as well. Talk to you in the morning! Thanks so much, I hope this helps.

Correlation mapping SIP call 2024-05-01 21_07_47.json

[jagnetta]

Good day!

I found some more of your writings in the wiki on github, in particular the parts about correlating with the correlation_id. So I've added some changes to the following two files attached to this comment.

The thing is that it does now correlate the A and B legs; however, only the INVITEs from the B leg is shown (see the screenshot), presumably as the remaining messages in the dialog don't have that particular header, just the INVITE has it. I think I read about something like this last night. If you guys have a tip, I could sure use it.

Thanks,
Jim

Fields mapping SIP call 2024-05-02 06_04_21.json
Correlation mapping SIP call 2024-05-02 06_04_14.json

[hamidrhashmi]

@jagnetta Have you followed the this Wiki page to configure two-way correlation?

[jagnetta]

Yes. That's the page I followed. I have correlation of the INVITES, but it's leaving out the rest of the messages in the dialog. @hamidrhashmi

[jagnetta]

@hamidrhashmi here is an example of the issue I'm describing in my latest comment from yesterday.

#466

This page also describes the issue, but it looks like there may be an answer in this post.

#278

[jagnetta]

The answer was in a post on this page:
#278

I needed to add "append_sid": true to the correlation_id stanza in the mapping rules. it works perfectly now.