IntroI have noticed there are analyzer tools for protocols such as RTP in the Telephony menu. Unfortunately I have been tasks to troubleshoot a network onto which an RTMPT ( RTMP over HTTP) has been deployed. I can see the packets in the log and entries both for HTTP and RTMP. Many entries within wireshark are labelled as HTTP. How do I extract meaningful QOS information from these "conversations" that take place between 2 IP addresses? We have delays and disconnections. ClarificationOne useful measurement is jitter but the only answer I have found is related to RTP: https://ask.wireshark.org/questions/12637/is-it-possible-to-analyze-jitter-from-the-captured-pcap-file
asked 20 Apr '16, 04:48  maythesource edited 20 Apr '16, 05:15 |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
What do you mean by "QOS information"?
Well, anything that could explain why there are delays and disconnections. I'm most likely using QOS wrong but I'm a developer tasked with doing analysis. Jitter, Delay, Bit Rate, Error Rate, Throughput, Order of Delivery.
An "ordinary" RTP prefers timely delivery to loss-free delivery of the data, therefore it uses UDP.
RTMPT uses TCP with its reliable delivery based on acknowledgements and retransmissions. Retransmissions are a more important source of jitter than the difference in delivery times of individual packets, and packet loss is a source of retransmissions.
So in your QoS analysis you should concentrate at the TCP layer, the layers above (HTTP, RTMPT) won't tell you much. If you won't lose packets on the way between source and destination, you'll get no retransmissions. If you get no retransmissions, it means you have no packet loss, and your only jitter comes from the difference of delivery times of individual packets.
Unfortunately, there is no function which would calculate jitter as a single number for a given TCP transmission, so you'll have to use
Statistics -> I/O Graphto see the regularity of TCP transmission graphically, or you'll have to use tshark to print packet timestamps and sizes into a text file and post-process that file (e.g. using a spreadsheet like Excel).For most traditional voice codecs, RTP uses fixed packet size and the notion of jitter makes sense; with newer codecs, this may not be true, so you may have a tough time if you'd capture only at destination. Capturing at (or right next to) source and destination devices simultaneously can give you information about propagation delays of individual packets.
The last thing is that the playback device only tolerates some amount of jitter (actually, it only buffers some amount of received audio samples before actually playing them), so if the packet carrying the next data comes later than the buffer containing the current data has been exhausted, there is a gap in the playback audio; if packets come in reverse order (which may also happen), the delayed packet is usually not played at all. So what sounds like a packet loss may be just jitter, i.e. when analysing TCP at receiving side only, you also have to take care whether Seq numbers grow monotonously even if there are no retransmissions or loss.