If you take a look at the headers, it's somewhat self explanatory -- this is for a 53 second call.
First it has the raw bytes in -- which includes dtmf, comfort noise, etc. Then it's broken down for where specifically it came.
If media_bytes or packets is 0 for either side, that will indicate real 1 way audio (assuming FS is in the media path).
"skip", "jb" (jitter buffer) and "flush" are all probably bad things.
On the way out, that means either the CPU couldn't keep up or maybe some issue with the input (not sure about the last one)
But for the inbound, that's an indication of some issue with the incoming media. It could be a real issue with the remote endpoint, or might just be a temporary issue with the link.
Adding skip+flush = 55 packets. Of the total media packets 2574, let's find a percentage: 55/2574 = 2.1% hmm. I'm not sure if that number means anything, but it's the percentage of incoming packets that went awry in some manner.
I see there's some past discussion on the mailing list -- it would be great if someone could pull together a wiki page that has all the accurate details...
|
rtp_audio_in_raw_bytes |
447772 |
|
rtp_audio_in_media_bytes |
442728 |
|
rtp_audio_in_packet_count |
2743 |
|
rtp_audio_in_media_packet_count |
2574 |
|
rtp_audio_in_skip_packet_count |
38 |
|
rtp_audio_in_jb_packet_count |
0 |
| rtp_audio_in_dtmf_packet_count |
152 |
|
rtp_audio_in_cng_packet_count |
0 |
| rtp_audio_in_flush_packet_count |
17 |
rtp_audio_in_largest_jb_size
|
0 |
| rtp_audio_out_raw_bytes |
364640 |
|
rtp_audio_out_media_bytes |
364640 |
|
rtp_audio_out_packet_count |
2120 |
|
rtp_audio_out_media_packet_count |
2120 |
|
rtp_audio_out_skip_packet_count |
0 |
|
rtp_audio_out_dtmf_packet_count |
0 |
rtp_audio_out_cng_packet_count
| 0 |
|
rtp_audio_rtcp_packet_count |
0 |
| rtp_audio_rtcp_octet_count |
0 |