issue with QOS visualization.

[lazedo]

Hello,

having an issue with QOS visualization.

heplify_server - a683cb969af2eeae93abc3f112c4dc25b2168dfc
homer-app - 6f9494b

the flow shows the RTCP messages

and they are listed in messages

but in the QOS tab i only see the media server (10.12.1.35) and the endpoints are missing

what could be causing this ?

thanks

[adubovikov]

please provide the payload of these "missing messages" It can be sender report without any information inside.

[adubovikov]

the version 1.3.0 has been released. Please install it and retest it.

[lazedo]

@adubovikov
Hello, tried 1.3.19 with same results.
capture is being done by heplify in a freeswitch server and sent to a heplify-server

i noticed that homer-ui restricts the types it handles.

and noticed the rtcp raw payload for the ones that came from devices (type = 207 extended report)

{
	"sender_information": {
		"ntp_timestamp_sec": 706767,
		"ntp_timestamp_usec": 644250000,
		"rtp_timestamp": 1507415936,
		"packets": 4534,
		"octets": 725440
	},
	"ssrc": 281769196,
	"type": 207,  <<<<<
	"report_count": 0,
	"report_blocks": [
		{
			"source_ssrc": 1671072604,
			"fraction_lost": 0,
			"packets_lost": 0,
			"highest_seq_no": 11183,
			"ia_jitter": 55,
			"lsr": 2472570665,
			"dlsr": 128451
		}
	],
	"report_blocks_xr": {
		"type": 6,
		"id": 0,
		"fraction_lost": 0,
		"fraction_discard": 0,
		"burst_density": 0,
		"gap_density": 0,
		"burst_duration": 0,
		"gap_duration": 0,
		"round_trip_delay": 0,
		"end_system_delay": 0
	},
	"sdes_ssrc": 281769196
}

but afaics they have the info required for homer-ui (strange that report_count = 0 ?).

one other thing that i also noticed (but probably not related) is that the ip address in sdp sent by freeswitch is advertised and does not correspond to the actual ip reported in the capture.
advertised => 10.26.26.2 , local => 10.12.2.2

zip file contains the results of the calls to qos and transaction as seen in homer-ui with chrome

homer.zip

[adubovikov]

Please install homer-app-1.4.0 and test again

[lazedo]

@adubovikov noticed no diff in the way homer-ui handles the rtcp packets. type 207 is still not handled

[adubovikov]

207 is the RTCP-XR. Can you please provide an example ?

[lazedo]

@adubovikov thanks for looking into this. check previous comment where i posted what was received from freeswitch and sent to heplify-server by heplify-client, the payload is from homer-app (using chrome debug tools to watch the qos returned values)

[adubovikov]

@RFbkak37y3kIY can you check it once you will have time ?

[lazedo]

@adubovikov this issue is related sipcapture/heplify#197
the same packet contains 200, 202 and 207. 200 is overridden by 207 and that's why its not selected .

[adubovikov]

@lazedo I don't think it related to 197. If heplify sent it as HEP RTCP it should be inserted into DB

[lazedo]

@adubovikov it is inserted in the db and retrieved but the type is 207 (the last in the packet). what's inserted in the db is not the real packet but a json representation of the same which is messed up because of 3 reports were received in same packet

[adubovikov]

this is that I was trying to say. It was inserted as a JSON representation and should be proceed in backend and UI. For now UI ignores that not equal 200-202. We will take a look on next occasion