handling of capture agent id

[fborot]

I just implemented the HEP3 protocol in C# and I found an inconsistency when using these 2 tools ("hepipe" and "captagent6") to send data to Homer; the "capture_agent_id" is treated as a payload type of "uint16" instead of "uint32" as per the protocol definition.
The only 2 chunk_types that I see treated as payload type "uint32" are the 2 timestamps (secs and usecs)

The function used to treat the "capture_agent_id" is "htons" instead of "htonl". You use "htonl" for the 2 timestamps as expected.

I checked the 2 PDF detailing the HEP3 protocol that are here :
https://github.com/sipcapture/HEP/tree/master/docs

I thought that maybe the Protocol definition changed and the pdf was not uploaded but the PCAP captures taken when sending packets to the Homer server using both tools (captagent6 and hepipe) use 4 bytes for that chunk_type, so it is still a "uint32" payload type.

That creates the problem on the server side of not identifying properly the agentid when writing the record to the tables.
In my case, I was using agent_i.d = 2001 which translate to "0x D1 07 00 00" in my Intel pc, (little endian) and when applying the "htonl" is was "0x 00 00 07 D1", and it was identified on the Homer server as agent_id = 0.
When looking at how the data was sent using the 2 tools (hepipe and captagent6) using the same value (2001) the bytes were: "0x07 D1 00 00", which is not what results from converting it to network byte order (big endian) using "htonl"

[adubovikov]

whats server do you use ? kamailio 4.4 ?

[fborot]

yes, the latest
kamcmd> core.version
kamailio 4.4.0-dev8 (x86_64/linux) a348a7
kamcmd>

[adubovikov]

yeah, looks like a weird issue :-( the best way use uint16 only.

we will try to find the best way to fix it on clients and servers side.

thank for the bug report!

[fborot]

no prob, I assume that probably the server side is also treating it as uint16 and that makes it harder to fix.
Maybe the easiest way to go around this is to change the protocol to use a payload type of uint16 instead since the server and maybe all clients are treating it like that. You can have up to 65536 possible agent_ids with a short type (2 bytes) which should be enough

[adubovikov]

not so easy, because the structure is uint32

https://github.com/kamailio/kamailio/blob/master/modules/sipcapture/hep.c#L395

and we send also uint32

https://github.com/sipcapture/captagent/blob/master/src/modules/transport/hep/transport_hep.h#L168

easy change to ntohl on the both sides but in some period you will get wrong result

or make a new capt_id chunk and send correct type and value.

[fborot]

quite a predicament, because both sides need to be in-sync. let me know what I can do to help

[dpocock]

@adubovikov I would suggest that new versions of the HEP client (captagent and embedded implementations) should send both the "legacy" value and some new value (with a new type ID) simultaneously in every packet.

New versions of the HOMER server would simply ignore the legacy value if they find the new value in a packet they receive.

[adubovikov]

agree, we will do it this way