546
edits
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
* Double packet: The number of duplicate packets for which the RTP sequence counter is identical. | * Double packet: The number of duplicate packets for which the RTP sequence counter is identical. | ||
* Jitter: This value models the difference of seen arrival time vs. expected arrival time based on the RTP timestamp. It is calculated according to the RTP RFC 3550. | * Jitter: This value models the difference of seen arrival time vs. expected arrival time based on the RTP timestamp. It is calculated according to the RTP RFC 3550. | ||
* Jitter buffer exceeded: This the amount of | * Jitter buffer exceeded: This the amount of packets within time windows for which the jitter is above a configured jitter buffer threshold. The threshold can be configured in SIP module settings. | ||
* Packet time delta: The is the arrival time delta value between two consecutive packets. Large value does not necessarily indicate a problem as there could be a silence or no video changes. In other cases, like constant video or audio streams, large values might indicate network delays. | * Packet time delta: The is the arrival time delta value between two consecutive packets. Large value does not necessarily indicate a problem as there could be a silence or no video changes. In other cases, like constant video or audio streams, large values might indicate network delays. | ||
* Clock skew: | * Clock skew: The clock skew is the difference of arrival time of two packets minus the difference of RTP timestamp (in relation to the clock rate). This value is taken into account for jitter calculation, but also gives indication about possible problem as an isolated value. A large clock skew can happen because of an unstable source clock which can result in dropped audio or video frames. A large clock skew can also happen by a network delay. The arrival time difference will be much higher than the initial send time difference. The former type of error can often be detected by checking if the skew remains positive or negative. If so, the clock is unstable. If not, it could be more likely a network delay. In this case, the clock skew "heals" shortly afterwards when delayed packets arrive in bursts faster than initially sent. Be aware, that the calculation assume a correct clock rate. For many codecs, the clock rate is fixed, for others the clock rate is estimated based on the timing of the packets at the beginning of the connection. If the clock rate is estimated wrongly, there will always be a positive or negative clock skew. But individual events of large clock skew changes are still detectable. | ||
* Max video frame duration: | * Max video frame duration: This value measures the duration of video frames sent by multiple packets. It is the arrival time between the first frame fragment and the last frame fragment. Usually the frame data is given to the operating system to send out individual UDP packets as fast as possible. So large frame durations indicate possible network delays or bottlenecks. | ||
==== '''IP addresses''' ==== | ==== '''IP addresses''' ==== |
edits