Asterisk RTCP

Before patch 10590 (which was applied to Asterisk 1.6) the RTCP data presented in Asterisk 1.4 were basically useless: For example packet loss values could be 10x higher than the number of total received packets, and only one of the two calls legs was being watched.

See Patch 10590 (updated and committed in June 2008)
"rtpqos-14-r119891.diff" is meant for Asterisk 1.4 and does also apply to Asterisk 1.4.30 after minimal manual intervention. Since Asterisk 1.4 does not receive new features this has not made it into subsequent 1.4 realeases.
Note: Packet2Packet bridging (aka p2p) will completely mess up the RTCP stats with this patch with up to wrongly reported 100% packet loss! So either make sure that p2p bridging does not occur (by using a force-enabled jitter buffer or by making sure transcoding is done), or disable the p2p code in rtp.c (which is really simple to do).

In Asterisk 1.6 the RTCP data are now provided with the help of the CHANNEL function.

Useful CLI commands

rtcp stats
sip show channelstats (Asterisk 1.6)
rtcp debug <ip>

Quality rules

• Packet loss < 1% (preferably 0.5%); with a packet loss of > 3% call quality will degrade audibly, at > 6% quality turns bad, and above 10% a call becomes entirely unacceptable.
• Delay/Latency < 150 ms (one way); to much delay can aslo affect/kill echo cancellation (think satellite link with 500-700 ms delay)
• RTT/Round Trip Time < 200-250 ms (RTT = delays of both directions added)
• Jitter < 30 ms. The meaning of the jitter value depends greatly on the jitter buffers involved. Jitter affects the packet loss
• "Bursts" of consecutively lost packets are bad bad bad (aka "drop out")
• codecs: Some codecs (g729, iLBC) are better at concealing a lost packets than others (g711), keyword "PLC": Packet Loss Concealment
• TOS/QoS/DiffServ settings can help to prioritize VoIP traffic on that part of the network you have control over

Questions

• Is it mandatory to have a proper NTP time setup to issue (and correctly honor received) RTCP reports? A: No, but it helps.
• What are the dimensions of the reported values - typically they are in seconds, however "reported jitter" appears to be shown in milliseconds?
• Is there a way to match a SSRC to a SIP UA, a call leg or call's unique ID? No, not easily, the SSRCs change often.

Abbreviations

RTCP: RTP Control protocol
SSRC: Synchronization Source
SR: Sender Report (issued by sites that also sent data in the past interval)
RR: Receiver Report (issued by sites that only received data)
RTT: Round Trip Time (how long does it take to the other side and then back to us = both delays/latencies added)
QOS: Quality of Service
rx: Receive
tx: Transmit (send)
Transit: Relative transit time for previous packet
DLSR (and LSR) allow a sender to calculate the round trip time of RTCP reports. (minus the internal delay on the remote side)
avg: average
stdev: standard deviation (statistics)

Examples

Example 1: CLI statistics of an unpatched Asterisk 1.4:

Note: There are two call legs with each a "sender" and a "receiver"

• Our Receiver:

SSRC: 1562797448
Received packets: 851
Lost packets: 0
Jitter: 0.0032
Transit: -0.0041
RR-count: 0

• Our Sender:

SSRC: 1172311862
Sent packets: 798
Lost packets: 0
Jitter: 0
SR-count: 3
RTT: 0.026000

Example 2: CLI output of "rtcp debug ip aa.bbb.cc. ...