search

sipcapture / homer-app

HOMER 7.x Front-End and API Server
http://sipcapture.io
GNU Affero General Public License v3.0
207 stars 85 forks source link

Improve QoS LSR display #358

Closed systemcrash closed 4 years ago

systemcrash commented 4 years ago

Currently heplify-server accepts RTCP/JSON verbatim. There may be room for improvements there. My concern here is LSR in Homer.

It seems there is currently no interpretation of the LSR fields. They are graphed, and other graph data disappear when LSR values are huge. These RTCP originate from endpoints beyond our control.

https://tools.ietf.org/html/rfc3550#page-40

   last SR timestamp (LSR): 32 bits
      The middle 32 bits out of 64 in the NTP timestamp (as explained in
      Section 4) received as part of the most recent RTCP sender report
      (SR) packet from source SSRC_n.  If no SR has been received yet,
      the field is set to zero.

e.g. here where the LSR values approach 4 billion...

Screenshot 2020-06-02 at 19 15 35

Interpreting the value as anything meaningful is not trivial. It doesn't seem to have any direct value or benefit for graphing. LSR has value only as relative to e.g. NTP timestamp.

Perhaps it could be unselected by default? Or get its own graph?

In fact, each of the values packets, octets, highest_seq_no, mos, ia_jitter, lsr, packets_lost all have their own scales and magnitudes, and it makes less sense to graph them all on the same graph.

Perhaps the QoS tab can have several graphs - one devoted to each value (each with its current check-box to dis/enable)?

systemcrash commented 4 years ago

So... could something like this be done via the JS functions in SIP call mapping?

lmangani commented 4 years ago

Older versions of HOMER used to split the charts - and nobody liked it as with many correlated legs, things were hard to read and figure out and I don't think we should ignore our history of failures so keep that in mind. If we do this, we need to think it through with a proper design goal.

Now, HOMER can't split charts apart just by applying mapping, so this would require U changes and new logic. @mikegoodstadt is redesigning this part specifically over the next weeks and months, so feel free to contribute any ideas you'd like to propose.

NOTE: The elegant way to handle LSR and other RTP/RTCP session parameters is to let the agents do it and send out a type 35 report. Raw RTCP should remain as such or it would impair the original purpose of type 5.

systemcrash commented 4 years ago

Just thinking out loud:

https://coverflowjs.github.io/coverflow/

Each graph gets its own 'cover' in a flow? Several graphs are all within view and selectable. Might be distracting for those who just want to "get work done". Might help increase positive emotions towards using your product. A bit older and 'rough' feel.

I've followed this guy for ages and he makes good product - some inspiration here, especially transitions:

https://d3js.org/

his showreel has a nice 'horizons' viz https://bl.ocks.org/mbostock/1256572

systemcrash commented 4 years ago

I like what cubism can do, it seems an ideal candidate for the separate scales for RTCP graphs.

systemcrash commented 4 years ago

Ridgeline could prove interesting if it is easy to control the scale.

But a custom chart may be the best way to go.

adubovikov commented 4 years ago

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

systemcrash commented 4 years ago

Because LSR is no longer selected by default, this is a win. Closing 😄