<div dir="ltr">Hello List,<div><br></div><div>I observe an interesting behavior. We use siptrace as an active capture agent for QXIP HOMER/HEPIC installations.<br clear="all"><div>The destination port and the source port in the HEPv3 Header are not correct if you use transport tcp for example.</div><div><br></div><div>My Question: is that intended or a bug and i should fill up an issue?</div><div><br></div><div>On udp, it's filled with 5060 or whatever your listening directive says.</div><div><br></div><div>I tested that with kamailio 5.5 and kamailio master.</div><div><br></div><div>I attached an HEPv3 capture from two kamailios (master) speaking with each other.</div><div>You need the <a href="https://github.com/sipcapture/hep-wireshark">https://github.com/sipcapture/hep-wireshark</a> lua dissector to read the capture.<br></div><div><br></div><div>10.0.2.15 (kamailio with uacreg and sipcapture/HEPv3 mode)<br>192.168.50.4 (kamailio as registrar)<br><br>Frame 1 shows an tcp transport register Request from 10.0.2.15 to 192.168.50.4 in HEPv3.<br>The Source Port in the HEP3 Protocol is not correct (its an highport / 45419).<br><br>Frame 4 shows the 401 answer and the Destination port is 0.<br>Frame 7 also had this behavior.<br><br><br>----- params (nearly at the end):<br>modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE")<br>modparam("siptrace", "hep_mode_on", 1)<br>modparam("siptrace", "hep_version", 3)<br>modparam("siptrace", "hep_capture_id", MY_HOMER_CAPTURE_ID) # capture agent id Limitation: 32-bit for HEPv3.<br>modparam("siptrace", "trace_to_database", 0)<br>modparam("siptrace", "trace_on", 1)<br>modparam("siptrace", "trace_mode", 1) # default 0, if 1 then you dont need call siptrace flag or sip_trace()<br></div><div><br></div><div><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Mit freundlichen Grüßen / Kind Regards<br>*Karsten Horsmann*<br></div></div></div>