[SR-Users] Question about siptrace destination/source port capture in HEPv3 mode

[Karsten Horsmann]

Hello List,

I observe an interesting behavior. We use siptrace as an active capture
agent for QXIP HOMER/HEPIC installations.
The destination port and the source port in the HEPv3 Header are not
correct if you use transport tcp for example.

My Question: is that intended or a bug and i should fill up an issue?

On udp, it's filled with 5060 or whatever your listening directive says.

I tested that with kamailio 5.5 and kamailio master.

I attached an HEPv3 capture from two kamailios (master) speaking with each
other.
You need the https://github.com/sipcapture/hep-wireshark lua dissector to
read the capture.

10.0.2.15 (kamailio with uacreg and sipcapture/HEPv3 mode)
192.168.50.4 (kamailio as registrar)

Frame 1 shows an tcp transport register Request from 10.0.2.15 to
192.168.50.4 in HEPv3.
The Source Port in the HEP3 Protocol is not correct (its an highport /
45419).

Frame 4 shows the 401 answer and the Destination port is 0.
Frame 7 also had this behavior.


----- params (nearly at the end):
modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "hep_version", 3)
modparam("siptrace", "hep_capture_id", MY_HOMER_CAPTURE_ID) # capture agent
id Limitation: 32-bit for HEPv3.
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_mode", 1) # default 0, if 1 then you dont need
call siptrace flag or sip_trace()



-- 
Mit freundlichen Grüßen / Kind Regards
*Karsten Horsmann*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220118/b5f257bb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dumphep3.pcap
Type: application/octet-stream
Size: 5290 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220118/b5f257bb/attachment.obj>