QoS not showing in Homer7, is captagent sending it?

[syadnom]

I just brought up homer7+heplify+influx using docker and have not changed anything ie bone stock.

I have captagent running on my pbx, sending via transport_hep and I'm seeing the calls in homer7 UI. I can't see the QoS data though. What am I missing? How do I tell if captagent is actually sending that?

captagent.xml has:

        <modules>
            <load module="transport_hep" register="local"/>
            <load module="protocol_sip" register="local"/>
            <load module="database_hash" register="local"/>
            <load module="protocol_rtcp" register="local"/>                                   $
            <load module="socket_rtcpxr" register="local"/>
            <load module="socket_pcap" register="local"/>
            <load module="socket_raw" register="local"/>

[lmangani]

Captagent will only do RTCP statistics and needs to capture and correlate those to SIP sessions. Please make sure you enabled an rtcp range in your socket_pcap configuration to begin with. If you're using NAT on your devices, you might also have to enable nat detection on the agent for pairing stats.

[syadnom]

entire socket_pcap file below. SIP is on 5060. I'm not modifying these systems except to change the IP and flip false to true in socket_pcap for RTCP. I'm lost.

systemctl shows these error lines: Apr 04 15:59:00 ip-172-26-4-102 captagent[20606]: [ERR] protocol_sip.c:350 SIP PARSE ERROR [-1] Apr 04 15:59:00 ip-172-26-4-102 captagent[20606]: [1B blob data] Apr 04 16:02:59 ip-172-26-4-102 captagent[20606]: [ERR] protocol_sip.c:131 This is not RTCP Apr 04 16:02:59 ip-172-26-4-102 captagent[20606]: [1B blob data] Apr 04 16:03:28 ip-172-26-4-102 captagent[20606]: [ERR] protocol_sip.c:131 Couldnot find this call Apr 04 16:03:28 ip-172-26-4-102 captagent[20606]: [1B blob data] Apr 04 16:04:19 ip-172-26-4-102 captagent[20606]: [ERR] protocol_sip.c:131 Couldnot find this call Apr 04 16:04:19 ip-172-26-4-102 captagent[20606]: [1B blob data] Apr 04 16:04:25 ip-172-26-4-102 captagent[20606]: [ERR] protocol_sip.c:131 Couldnot find this call Apr 04 16:04:25 ip-172-26-4-102 captagent[20606]: [1B blob data]

socket_pcap.xml: <?xml version="1.0"?>

portrange 5060-5091 portrange 5060-50000

On the server side I'm getting this... but I don't have json enabled just hep. The IP and port are right on the client because data is making it to the server.

heplify-server | 2019/04/04 21:59:00.886248 decoder.go:120: WARN parseStartLine err: received err while parsing start line: parseStartLineRequest err: could not get "/" pos in parts[2] heplify-server | "Sip0SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP

:5090;rport;branch=3cxtnl-iPhoneTID-1\r\nVia: SIP/2.0/UDP 127.0.0.1:5060;rport=5060;received=;branch=z9hG4bK-524287-1---15d51f111a764e06\r\nCall-ID: ae266558714e4d4eaee1a29a00b8260c\r\nFrom: @;tag3cx=ea147b8696164e9d869b97997fb7a3b2>;tag=19e6217a\r\nTo: \"Dan Denson\" ;tag=fdfc09400acf4b338b6a55363db9b9e9\r\nCSeq: 2 BYE\r\nContent-Length: 0\r\n\r\n" heplify-server | nodeID: 131137536, protoType: 1, version: 2, protocol: 6, length: 447, flow: :6331->172.26.4.102:5090 heplify-server | db_1 | 2019-04-04 21:59:01.076 UTC [54] ERROR: invalid input syntax for type json db_1 | 2019-04-04 21:59:01.076 UTC [54] DETAIL: Character with value 0x04 must be escaped. db_1 | 2019-04-04 21:59:01.076 UTC [54] CONTEXT: JSON data, line 1: ...d":"ae266558714e4d4eaee1a29a00b8260c","method":"Y... db_1 | COPY hep_proto_1_call, line 1, column data_header: "{"ruri_domain":"127.0.0.1","ruri_user":"","from_user":"000","to_user":"","pid_us..." db_1 | 2019-04-04 21:59:01.076 UTC [54] STATEMENT: COPY hep_proto_1_call(sid,create_date,protocol_header,data_header,raw) FROM STDIN heplify-server | 2019/04/04 21:59:01.077119 postgres.go:271: ERR pq: invalid input syntax for type json heplify-server | 2019/04/04 21:59:01.077339 postgres.go:279: ERR pq: Could not complete operation in a failed transaction heplify-server | 2019/04/04 21:59:03.962015 decoder.go:120: WARN parseStartLine err: received err while parsing start line: parseStartLineRequest err: could not get "/" pos in parts[2] heplify-server | "l\x02Sip0SIP/2.0 407 Proxy Authentication Required\r\nVia: SIP/2.0/UDP [::ffff:]:6331;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=clnt.1-7e15d83480324bcb974169bc358b3355\r\nVia: SIP/2.0/TCP 10.39.40.135:50195;rport;branch=z9hG4bKPja472299e690b43e4815fe6b6bcf45287;alias\r\nProxy-Authenticate: Digest nonce=\"414d53595ca67e2750:2ea6f600a4573440a18ef4e584539a60\",algorithm=MD5,realm=\"3CXPhoneSystem\"\r\nTo: \"Dan Denson\";tag=1dd06b1b\r\nFrom: \"Dan Denson\" < sip:0@dt.mt.3cx.us>;tag=32ac48bec491464fbe84eb46d8009ce5\r\nCall-ID: e4482d2c524c4b10b02419d3b138e357\r\nCSeq: 41493 REGISTER\r\nContent-Length: 0\r\n\r\n" heplify-server | nodeID: 131137536, protoType: 1, version: 2, protocol: 6, length: 622, flow: 172.26.4.102:5090->:6331 heplify-server | heplify-server | 2019/04/04 21:59:03.982218 decoder.go:120: WARN parseStartLine err: received err while parsing start line: parseStartLineRequest err: could not get "/" pos in parts[2] heplify-server | "j\x02Sip0SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP [::ffff:]:6331;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=clnt.1-7e15d83480324bcb974169bc358b3355\r\nVia: SIP/2.0/TCP 10.39.40.135:50195;rport;branch=z9hG4bKPjf78fd1e0d277405fbfc23dc46bf06125;alias\r\nContact: \"Dan Denson\";expires=120\r\nTo: \"Dan Denson\";tag=90621529\r\nFrom: \"Dan Denson\"< sip:0@dt.mt.3cx.us>;tag=32ac48bec491464fbe84eb46d8009ce5\r\nCall-ID: e4482d2c524c4b10b02419d3b138e357\r\nCSeq: 41494 REGISTER\r\nUser-Agent: 3CXPhoneSystem 16.0.0.1581 (1581)\r\nContent-Length: 0\r\n\r\n" heplify-server | nodeID: 131137536, protoType: 1, version: 2, protocol: 6, length: 620, flow: 172.26.4.102:5090->:6331 heplify-server | On Thu, Apr 4, 2019 at 2:54 PM Lorenzo Mangani wrote: > Captagent will only do RTCP statistics and needs to capture and correlate > those to SIP sessions. Please make sure you enabled an rtcp range in your > socket_pcap configuration to begin with. If you're using NAT on your > devices, you might also have to enable nat detection on the agent for > pairing stats. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

[lmangani]

When you enable the RTCP socket the agent will capture reports for calls it has never seen an INVITE for hence the This is not RTCP message. If this does not disappear as new calls arrive, the SDP possibly carries NATed details.

[syadnom]

PBX is on EC2 so it's 1:1 NAT. Is there something I should configure for that to be recognized?

On Thu, Apr 4, 2019 at 5:39 PM Lorenzo Mangani notifications@github.com wrote:

When you enable the RTCP socket the agent will capture reports for calls it has never seen an INVITE for hence the This is not RTCP message. If this does not disappear as new calls arrive, the SDP possibly carries NATed details.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sipcapture/captagent/issues/208#issuecomment-480100649, or mute the thread https://github.com/notifications/unsubscribe-auth/AJRXZda9CoYlo4aEjnqPlEAwaxeV4g7sks5vdo0ugaJpZM4cdoGV .

[adubovikov]

do you see the rtp/rtcp streams from public or private IP addreses ? And what do you have in the SDP?

[negbie]

I think he just uses a 3CX PBX which uses a special tunnel encapsulation https://www.3cx.com/docs/3cx-tunnel-session-border-controller/ So the SIP, RTCP Port correlation does not work correctly I guess.

Some time ago I wrote a special decoder for a guy and sent him a special heplify version https://github.com/sipcapture/heplify-server/issues/68 It's not public because 3CX wouldn't like it ;)

[UbuntuEvangelist]

same here

[lmangani]

Closing for inactivity. Reopen if needed.