OPTIONS Method as part of a call dialog

[so6erholic]

Is it possible to view OPTIONS packets as part of an entire call flow / call dialog along with the INVITES, ACK, INFO packets. We send options every minute during a call but we cant see the packets as part that call dialog we see them separately

[github-actions]

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

[lmangani]

Hello @so6erholic if the OPTION method is part of the same session (call-id) then it should be displayed as part of the flow. If this is not the case, to force it all you need to do is extend the mapping to also pull OPTIONS with the same call-id from the other partition where they are stored (similarly as you would see for RTCP statistics)

[github-actions]

Please star this repository to motivate the developers and to get higher priority! ⭐

[lmangani]

See my comment above with the solution. Extend the call search mapping to look for messages in the default partition with the same callid, for example:

{
        "source_field": "data_header.callid",
        "lookup_id": 1,
        "lookup_profile": "default",
        "lookup_field": "data_header.callid",
        "lookup_range": [
            -300,
            200
        ]
}

[lmangani]

Be brave and try it to understand how this works. Also if you have time for this, you probably have time to ⭐ the project 😉

[so6erholic]

Sure. Thanks a lot for your help :)

[github-actions]

Please star this repository to motivate the developers and to get higher priority! ⭐

[so6erholic]

Hi @lmangani Please check this. I setup homer on my local machine and tried sending simulated sip traffic to it. With Invite 180 200 ACK INFO and OPTIONS as part of call dialog.

See in images, it still lists options separately even though these have the same Call id. Is it by design that homer doesn't correlate options as part of the call dialog?

My sip -call mapping settings are as per your suggestion:

[
{
"source_field": "data_header.callid",
"lookup_id": 100,
"lookup_profile": "default",
"lookup_field": "sid",
"lookup_range": [
-300,
200
]
},
{
"source_field": "data_header.callid",
"lookup_id": 5,
"lookup_profile": "default",
"lookup_field": "sid",
"lookup_range": [
-300,
200
]
},
{
"source_field": "protocol_header.correlation_id",
"lookup_id": 1,
"lookup_profile": "call",
"lookup_field": "sid",
"lookup_range": [
-300,
200
]
},
{
"source_field": "data_header.callid",
"lookup_id": 1,
"lookup_profile": "default",
"lookup_field": "data_header.callid",
"lookup_range": [
-300,
200
]
}
{
"source_field": "data_header.callid",
"lookup_id": 1,
"lookup_profile": "call",
"lookup_field": "data_header->>'callid'",
"lookup_range": [
-300,
200
],
"input_function_js": "var returnData=[]; for (var i = 0; i < data.length; i++) { returnData.push(data[i]+'_b2b-1'); }; returnData;"
}
]

[so6erholic]

Any update here? Let me know if this is possible or is it by design in homer?

[lmangani]

This is optional by design. Some people want it some do not. As explained, the messages are stored in different partitions for calls/registrations/default and I already provided with a method to play with which your current validation doesn't prove wrong just yet. We just can't tell by just looking without knowing what's in the database to find. Screenshots are hard to read for many when we're around. Someone might try to replicate it in the spare time on our side to confirm with our examples, but note this is best effort so we'll check this next week or at the first opportunity. It's funny cause it seems you didn't have time to star our repository either 😉