sipcapture / hep Goto Github PK

Assuming that we want to use HEP to encapsulate an HTTP2 message (frame), max message size defined in HEP header (currently 65535) can be restrictive. i guess header change means new HEP version ?

What is the purpose of the "authenticate key" chunk type?
Is it a passphrase used by the server to accept the packet?

Description

When starting the hepsub-cgrates project using the command nodejs cgrates.js, the API server starts, but immediately logs an error related to the registration API.

Expected Behavior

The API server should start without any errors, and it should successfully register with the backend service.

Actual Behavior

The API server starts and logs the following output and error:

API Server started 18088
REGISTER API ERROR 400 Bad Request

Configuration

Here is the relevant portion of the config.js file:

var config = {

  backend: 'http://localhost:9080/api/v3/agent/subscribe',

  token: 'gMjKsDIEnoBYuRlGJJLRyTHZZBNIvbcMHDVgcetKWvfbptajLyAMqWUOIHCZJmwcucSDRsILYmZfXaDY',

  service: {

    "uuid": Math.random().toString(36).substring(7),

    "host":"127.0.0.1",

    "port": 18088,

    "protocol": "http",

    "path": "/get",

    "type": "cdr",

    "ttl": 300,

    "node": "cgrates",

    "gid": 10

  },

  debug: true,

  cgrates: {

    "url": "http://192.168.0.115:2080/jsonrpc",

    "tenant": "cgrates.org",

    "hep_field": "callid"

  }

};

Environment

• HOMER installation guide used: HOMER Quick Install Docker
• CGRates running on my local machine.

Please advise on any steps that can be taken to resolve this error.
Thank you!

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"

Looking some packages i can see the lenght metadata don't matches with the real header size (Version and lenght fields included and payload excluded as says the protocol), timestamps and Capture ID of node fields keeps outs of this margin, being watched as a HEP.v1 header adding new fields with a constaint size that are excluded of the header lenght.

Too I can see that the timestamp don't match with actually dates, they are from ¡2044!

Please, resolve my boubts as soon as possible.

Thanks in advance

Jaime Olmedo Zazo

Example state:

00 00 00 01 00 07 02; protocol family = 2 (IPv4)

wheareas IANA documentation for protocol family state:

1 | IP (IP version 4)

I have a parser written in Go that I will be putting in its own repo soon. I support hep v1 and hep v3 but I can't find docs on hep v2. Do they exist anywhere?

Hi sipcapture team,

We noticed that HEP parsers and decoders (heplify-server as one) need HEP "Correlation ID" chunk of type 0x0011 ("Internal correlation id" in specification doc) to properly parse and decode HEP packet which is not stated or obvious in document nor given example.

If this makes sense, please update given protocol specification :)

Thanks and regards,
I