search

sipcapture / homer

HOMER - 100% Open-Source SIP, VoIP, RTC Packet Capture & Monitoring
https://sipcapture.org
GNU Affero General Public License v3.0
1.61k stars 240 forks source link

RTCP Data Missing - GUI issue #412

Closed Demolish50 closed 2 years ago

Demolish50 commented 4 years ago

I think there is a bug preventing the GUI from showing some QoS (RTCP) data.

I'm running the latest version available via docker, installed via docker about 12 days ago.

I'm able to see bidirectional RTCP data on the PBX<-->SIP trunk provider just fine in the GUI/QoS tab. I'm also to see RTCP data from my PBX to my endpoints in the QoS tab but not endpoints to the PBX.

The RTCP data from the endpoints to the PBX is missing from the GUI. I say it's missing from the GUI only as when I inspect the "qos" section with f12 in Chrome and pull up the call-id, I can see bidirectional data in the f12 debug window but homer itself only shows one direction in the QoS tab.

I've attached a screenshot but it's hard to understand as I blanked out the public IP addresses. I can provided an unmasked screenshot to private addresses as required.

In the screenshot in the network debug window you can see #6 on the right. It is RTCP data for the RTP stream from the my endpoint (phone) to the PBX which is not in the homer QoS tab. I've blocked out my public addresses. #7 on the right is data from the PBX to my endpoint and is represented in the QoS tab on the left of the screenshot. The address ending in 9.18 is where my endpoints are. The address ending in 57.68 is where the PBX is. You can see IP xx.xx.9.18 to xx.xx.57.68 is missing in the gui.

capture2

adubovikov commented 4 years ago

I think the issue has been fixed in the homer-view. @AlexeyOplachko can you please confirm it was back ported to the homer-ui as well ?

adubovikov commented 4 years ago

@Demolish50 and if you can provide the csv dump of your rtcp table with these rtcp reports, it will help a lot to reproduce the issue in our lab.

Demolish50 commented 4 years ago

@adubovikov Sorry, to be clear you want me to export the table from postgres to a CSV? Or do you mean from that Chrome debug somehow?

Sure I can do that, I just need a private way to provide it.

Demolish50 commented 3 years ago

I updated with the new docker containers yesterday and saw some nice changes but this issue still exists.

lmangani commented 3 years ago

@AlexeyOplachko could you take a look when possible?

Demolish50 commented 3 years ago

The RTCP data that is not showing in the GUI is generated by Sangoma phones. They generate RTCP XR. I can provide capture if provided private way to provide it.

lmangani commented 3 years ago

There's RTCP XR and RTCP XR/Vq - they are not the same - for the latter you can try https://github.com/negbie/heplify-xrcollector

Demolish50 commented 3 years ago

There's RTCP XR and RTCP XR/Vq - they are not the same - for the latter you can try https://github.com/negbie/heplify-xrcollector

Can you please help me understand. I'm unaware that they are not the same. We are collecting the RTCP XR data as you can see in the debug window or am I misunderstanding?

I'll try it for giggles but I don't follow.

I tried but I can't have it bind to the same port to listen as it's already bound by heplify.

lmangani commented 3 years ago

Use a different port. RTCP-XR senders usually feature a different endpoint configuration since they are out-of-band.

Demolish50 commented 3 years ago

For the listening port? If I tell it to listen on something other than 5060 I assume it won't capture anything or are you suggesting I need to reconfigure my endpoints.

"listen udp :5060: bind: address already in use"

Demolish50 commented 3 years ago

OK I think I got that all sorted now that I understand. I configured the endpoints to send VQ RTCP data to the system (the PBX) hosting the xrcollector. I used port 8005. The xrcollector is sending data to the server running heplify and everything else. I can see in the log output of the xr collector (./heplify-xrcollector -xs :8005 -hs 10.108.0.2:9060 -hi 5000 -debug) the traffic from the phones and it appears to have sent it over to the heplify server but I still don't see the data in homer. I still see the data from the phones like I always (via debug window in Chrome) have though but it looks like regular RTCP XR data to me or I misunderstand something about publish.

Before these config changes the phones were only sending RTCP XR as VQ RTCP Report was explicitly disabled on the phone.

Demolish50 commented 3 years ago

Here is the RTCP XR data as presented via the chrome bug window.

2: {captureId: "5000", correlation_id: "5deeb2698fdbf6c@192.168.1.135",…} captureId: "5000" correlation_id: "5deeb2698fdbf6c@192.168.1.135" create_date: "2020-09-28T14:23:55.061131Z" dbnode: "local" dstIp: "XX.XX.57.68" dstPort: 16773 id: 43783 node: ["local", "5000"] 0: "local" 1: "5000" payloadType: 5 profile: "" proto: "rtcp" protocol: 17 protocolFamily: 2 raw: "{"sender_information":{"ntp_timestamp_sec":3810291834,"ntp_timestamp_usec":1975240000,"rtp_timestamp":2687691728,"packets":500,"octets":80000},"ssrc":1856360383,"type":207,"report_count":1,"report_blocks":[{"source_ssrc":0,"fraction_lost":0,"packets_lost":1,"highest_seq_no":12559,"ia_jitter":0,"lsr":0,"dlsr":0}],"report_blocks_xr":{"type":7,"id":0,"fraction_lost":0,"fraction_discard":0,"burst_density":0,"gap_density":0,"burst_duration":0,"gap_duration":10000,"round_trip_delay":0,"end_system_delay":30},"sdes_ssrc":1856360383}" sid: "5deeb2698fdbf6c@192.168.1.135" srcIp: "XX.XX.9.18" srcPort: 12183 timeSeconds: 1601303035 timeUseconds: 61131 3: {captureId: "5000", correlation_id: "5deeb2698fdbf6c@192.168.1.135",…} 4: {captureId: "5000", correlation_id: "5deeb2698fdbf6c@192.168.1.135",…} 5: {captureId: "5000", correlation_id: "5deeb2698fdbf6c@192.168.1.135",…}

Compared to the one that does show in the GUI, type value is different. This XR is type 7. The working is type 0, if that matters.

lmangani commented 3 years ago

I see this was never completer or confirmed - is this still an issue which needs assistance?

Demolish50 commented 3 years ago

yes it is still broke as of three weeks ago

On Mon, Jul 5, 2021 at 4:12 PM Lorenzo Mangani @.***> wrote:

I see this was never completer or confirmed - is this still an issue which needs assistance?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sipcapture/homer/issues/412#issuecomment-874330928, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACASUB6C4RMYL3AHTGQ3UKTTWIN37ANCNFSM4QLCBUDA .

lmangani commented 3 years ago

@AlexeyOplachko @RFbkak37y3kIY please reconfirm and fix this issue

adubovikov commented 3 years ago

Please install homer-app-1.4.0 and test again!

adubovikov commented 2 years ago

@Demolish50 i will close the ticket. Please reopen if it will be needed

Demolish50 commented 2 years ago

The issue still persists.

The only thing I can think of is maybe Homer doesn't like source_ssrc being 0? That is the only difference I can really find. The issue persists as before. Chrome network debug shows the traffic, its just not graphed in homer in the qos tab.