RTPAUDIOQOS Demystified
How to get such data
Add such line in h context:
exten => h,n,NoOp(RTPAUDIOQOS: ${CHANNEL(rtpqos,audio,all)})
How to read such data
ssrc=254186206;themssrc=2024901615;lp=0;rxjitter=0.020917;rxcount=150;txjitter=0.000000;txcount=83;rlp=0;rtt=14818.715000
- Our Receiver
- ssrc - our ssrc
- rxcount - no. received packets/Received packets
- lp - lost packets/Lost packets
- rxjitter - our calculated jitter(rx)/Jitter
- Our Sender
- themssrc - their ssrc
- txcount - transmitted packets/Sent packet
- rlp - remote lost packets/Lost packets
- txjitter - reported jitter of the other end/Jitter
- rtt - round trip time/RTT
Synchronization source (SSRC)
The source of a stream of RTP packets, identified by a 32-bit numeric SSRC identifier carried in the RTP header so as not to be dependent upon the network address. All packets from a synchronization source form part of the same timing and sequence number space, so a receiver groups packets by synchronization source for playback. Examples of synchronization sources include the sender of a stream of packets derived from a signal source such as a microphone or a camera, or an RTP mixer (see below). A synchronization source may change its data format, e.g., audio encoding, over time. The SSRC identifier is a randomly chosen value meant to be globally unique within a particular RTP session (see Section 8). A participant need not use the same SSRC identifier for all the RTP sessions in a multimedia session; the binding of the SSRC identifiers is provided through RTCP (see Section 6.5.1). If a participant generates multiple streams in one RTP session, for example from separate video cameras, each MUST be identified as a different SSRC.
Source: http://www.ietf.org/rfc/rfc3550.txt
Jitter
Jitter is a more complex problem than latency and packet loss. It's the variation in latency time from one packet to the next. It causes packets to arrive out of order, leaving gaps in the framing sequence of the voice signal. Jitter is at its worst when voice traffic must travel through several routers on the network. The more hops, the worse jitter can get. Different routers, especially those at ISPs, may be configured to queue and forward different kinds of traffic in different ways. Others may be load-balancing, which can contribute to jitter. The chief goal of QoS protocols is to eliminate jitter. Devices called jitter buffers, in endpoints and VoIP servers, can minimize the effect of jitter, too. But, like PLC measures, they do so by increasing latency. (Switching to VoIP By Theodore Wallingford)
In the given example:
ssrc=254186206;themssrc=2024901615;lp=0;rxjitter=0.020917;rxcount=150;txjitter=0.000000;txcount=83;rlp=0;rtt=14818.715000
How do I interprete the jitter value ? Is the value 0.020917 good ? Bad ? Is there a unit behind this value ?
Answer:
It's a ratio of out-of-order (jittered) to in-order packets, calculated progressively. Due to the progressive calculation, it's not exactly 3/147, in this case, but it's close enough to know that 3 packets were received out-of-order. The closer the value is to 0, the better. -- Tilghman Lesher
To get approximate value of received packets out of order do such calculations: rxcound * rxjitter (in our example 150 * 0.020917 ~= 3 packets). Same for transmitting end: txcount * txjitter.
