sipcapture / hepfix.js Goto Github PK

Hi,

I see the following error message after receiving a (268) QOS REPORT from our ACME/ORACLE SBC

268: QOS REPORT
{ CallID: '[email protected]' }
{ type: 'HEP',
version: 3,
payload_type: 'JSON',
captureId: 2017,
capturePass: 'oracme',
ip_family: 2,
protocol: 17,
proto_type: 35,
srcIp: undefined,
dstIp: undefined,
srcPort: undefined,
dstPort: undefined,
correlation_id: '[email protected]',
mos: 440,
time_sec: 1567681411,
time_usec: 940 }
Sending HEP3 Packet to localhost:9060...
HEP3 Error sending!
TypeError: Cannot read property 'split' of undefined
at Object.encapsulate (/var/opt/hepfix.js/node_modules/hep-js/index.js:89:23)
at sendHEP3 (/var/opt/hepfix.js/hep-client.js:121:31)
at Object.preHep (/var/opt/hepfix.js/hep-client.js:88:5)
at MOSit (/var/opt/hepfix.js/hepfix.js:47:13)
at fixHandler (/var/opt/hepfix.js/hepfix.js:212:5)
at fixHandler (/var/opt/hepfix.js/hepfix.js:112:4)
at Socket. (/var/opt/hepfix.js/hepfix.js:243:2)
at Socket.emit (events.js:198:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)

The rest of the SIP messages are handled correctly, without errors.

Hello.
Since restructure version isn't limited in package.json npm Uses recent 3.0.0 version which isn't compatible with Hepfix. It crashes on EncodeStream, because they made buffer a mandatory EncodeStream arg. Manually changing restructure version to 2.0.1 before build fixes the problem.

Oct 22 14:03:08 localhost.localdomain systemd[1]: hepfix.service: main process exited, code=exited, status=1/FAILURE
Oct 22 14:03:08 localhost.localdomain node[1745]: at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
Oct 22 14:03:08 localhost.localdomain node[1745]: at Socket.Readable.push (node:internal/streams/readable:228:10)
Oct 22 14:03:08 localhost.localdomain node[1745]: at readableAddChunk (node:internal/streams/readable:289:9)
Oct 22 14:03:08 localhost.localdomain node[1745]: at addChunk (node:internal/streams/readable:315:12)
Oct 22 14:03:08 localhost.localdomain node[1745]: at Socket.emit (node:events:513:28)
Oct 22 14:03:08 localhost.localdomain node[1745]: at Socket.<anonymous> (/opt/homer/hepfix/1.0.1/hepfix.js:247:2)
Oct 22 14:03:08 localhost.localdomain node[1745]: at fixHandler (/opt/homer/hepfix/1.0.1/hepfix.js:68:23)
Oct 22 14:03:08 localhost.localdomain node[1745]: at Object.exports.writeHandshake (/opt/homer/hepfix/1.0.1/sipfix.js:281:15)
Oct 22 14:03:08 localhost.localdomain node[1745]: at new $1ed46182c1410e1d$export$9b4f661deaa36c3e (/opt/homer/hepfix/1.0.1/node_modules/restructure/dist/main.cjs:110:46)
Oct 22 14:03:08 localhost.localdomain node[1745]: TypeError: Cannot read properties of undefined (reading 'buffer')
Oct 22 14:03:08 localhost.localdomain node[1745]: ^
Oct 22 14:03:08 localhost.localdomain node[1745]: this.view = new DataView(this.buffer.buffer, this.buffer.byteOffset, this.buffer.byteLength);
Oct 22 14:03:08 localhost.localdomain node[1745]: /opt/homer/hepfix/1.0.1/node_modules/restructure/dist/main.cjs:110
Oct 22 14:03:08 localhost.localdomain node[1745]: REPLYING WITH ID: 257
Oct 22 14:03:08 localhost.localdomain node[1745]: GOT HANDSHAKE ID:  256
Oct 22 14:02:57 localhost.localdomain node[1745]: HEPFIX.js Listening on port 4739 ...

Hello,

I am using hefix.js to collect IPFIX from Oracle SBCs and convert them into HEP. Then, i use heplify-server to store data into homer database.

I´ve attached some messages from hefix.js debug output (both ipfix and hep debug enabled), to find a message related to QOS REPORT just search by 268: QOS REPORT on attached log.

The HEP is then processed by heplify and below there´s the log related to an QOS message database insertion. As you can see "RAW" column is being populated with "[object Object]".
On the Homer side, i´ve created a mapping to get data from ID 35, a exact copy of default RTP-FULL-REPORT (ID 34) but with ID changed to 35.

The messages are then shown on the grid using this template but when clicking on correlation id nothing is loaded with "Uknown error" due to the RAW data being just [object Object].

2020-05-13T15:54:54+01:00 DBG [sql] COPY hep_proto_35_default(sid,create_date,protocol_header,data_header,raw) FROM STDIN

[[email protected]:5060 2020-05-13T15:54:53.000134+01:00 {"protocolFamily":2,"protocol":17,"srcIp":"127.0.0.1","dstIp":"127.0.0.1","srcPort":0,"dstPort":0,"timeSeconds":1589381693,"timeUseconds":134,"payloadType":35,"captureId":"2017","capturePass":"oracme","correlation_id":"[email protected]:5060"} {"node":"2017","proto":"rtcpxr"} [object Object]

hepfix.log

Homer postgres database:

First Thanks for your great approach!

i'm testing the hepfix.js with 4600 SCZ7.3.0 MR-2 Patch 5.
TCP Handshake works:

HEPFIX.js Listening on port 4739 ...
GOT HANDSHAKE ID:  256
REPLYING WITH ID: 257

sbc# show comm-monitor 

16:08:22-127
Client                     State                 Protocol
===========================================================
212.117.192.70:4739        Connected             TCP    

but after handshake he sends complete different SetID

Cisco NetFlow/IPFIX
    Version: 10
    Length: 20
    Timestamp: Jan  1, 1970 01:00:00.000000000 CET
    FlowSequence: 0
    Observation Domain Id: 0
    Set 1 [id=0] (Data Template):  <--
        FlowSet Id: Data Template (V9) (0)
        FlowSet Length: 4

console output of hepfix.js:

Invalid/Unsupported Type:  undefined
Invalid/Unsupported Type:  undefined
Invalid/Unsupported Type:  undefined
Invalid/Unsupported Type:  undefined

on which ACME OS Version/Platform did you your test?
do you may have a reference for screen ipfix stream?

thanks in advance

Im using oracle sbc to originate this traffic, for some reason the CSeq line does not appear to be terminated.

2021-05-12T17:30:08-04:00 WARN could not find a valid CSeq in packet
"SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP ...:5060;branch=z9hG4bKkju2cl009gd2dgq58rn0;received=...\r\nCall-ID: 97311fc32e40429e3b0361c1957d5fbc0200o0g6p3200@...\r\nTo: sip:ping@...\r\nFrom: sip:ping@...;tag=30528f7f58da7664c49cb2144eaa67760o0g6p3\r\nCSeq: 223474 "
nodeID: 2017, protoType: 1, version: 2, protocol: 17, length: 289, flow: ...:5060->...:5160

Hello,

I do see that packet captured via comm-monitor + hepfix.js, is timestamped 1 minute later than the same packet captured by the other participant.

Do you have any idea it the problem is on the comm-monitor side or in hepfix.js ?

Regards.

David.