issue with `QOS` visualization.

lazedo commented 4 years ago

Hello,

having an issue with QOS visualization.

heplify_server - a683cb969af2eeae93abc3f112c4dc25b2168dfc homer-app - 6f9494b140b51400dc6f24fe413454e107360b33

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 commented 4 years ago

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

adubovikov commented 4 years ago

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

lazedo commented 3 years ago

@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 commented 3 years ago

Please install homer-app-1.4.0 and test again

lazedo commented 3 years ago

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

adubovikov commented 3 years ago

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

lazedo commented 3 years ago

@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 commented 3 years ago

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

lazedo commented 3 years ago

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

adubovikov commented 3 years ago

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

lazedo commented 3 years ago

@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 commented 3 years ago

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

sipcapture / homer-app

issue with `QOS` visualization. #400