Hi,
i’m encoutering a bug with the sip show channelstats command:
sometimes the “packet lost” suddenly increase, usually with value higher than the number of packets received…
here is a capture:
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
217.15.80.163 67a6c04e225 00:00:26 0000001249 0000000000 ( 0.00%) 0.0000 0000001248 0000000000 ( 0.00%) 0.0002
on second later:
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter
217.15.80.163 67a6c04e225 00:00:27 0000001318 0000042135 (96.97%) 0.0000 0000001318 0000000000 ( 0.00%) 0.0003
i’m running with Asterisk 1.8.21.0
do you have any clues about this bug?
Turn on RTCP debugging and check that the other side is transmitting sensible values for the number of packets sent.
OK Here is the debug result:
217.15.80.163 38585f395cf 00:00:27 0000001269 0000028284 (95.71%) 0.0000 0000001254 0000000000 ( 0.00%) 0.0002
Got RTCP from 217.15.80.163:52251
- Sent RTCP SR to 217.15.80.163:52251
Our SSRC: 1629729828
PT: 200(Sender Report)
Sent(NTP): 1400658436.1382940672
Sent(RTP): 96338400
Sent packets: 494
Sent octets: 79040
Report block:
Fraction lost: 253
Cumulative loss: 28284
Reception reports: 1
SSRC of sender: 4094149130
NTP timestamp: 3609647236.0073371648
RTP timestamp: 49600
SPC: 310 SOC: 49600
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 39523
Sequence number cycles: 0
Interarrival jitter: 13
Last SR(our NTP): 55423.4026531840
DLSR: 4.9790 (sec)
RTT: 22(sec)
IA jitter: 0.0003
Their last SR: 3632550336
DLSR: 65511.6650 (sec)
so, tell me if i got it:
RTCP informations are sent by extensions (or here by the sip trunk provider) ?
if yes, it means that both extensions and our sip trunk providers have a problem with the RTCP report?
You will need to cross match the RTCP report with the other information to work out where the problem lies. I’d be surprised if it was in Asterisk.
i made a capture with tcpdump.
192.168.122.140 1e9738ac161 00:01:47 0000003060 0000045754 (93.73%) 0.0000 0000003066 0000000000 ( 0.00%) 0.0001
so, here, the IPBX (192.168.122.11) just sent a RTCP packet to the extension with “Faction lost 254/256” and “Cumulative number of packets lost: 45754”
The fact is, with such amount of packet lost, the conversation would be really bad, but it’s not the case, the communication was perfect…
for me, Asterisk send wrong information : i made 3 captures, and everytimes, it was asterisk which sent informations about lost packets, and not the extension.
i’m sorry , i’m really lost with RTCP .
Please confirm that the peer has sent packets with no gaps in their sequence numbers. RFC 1889 Appendix 3, will produce invalid statistics if this condition is not met and the SSRC remained the same.
I think it is possible that Asterisk does not maintain separate statistics for each SSRC, but you would need to show SSRCs and sequence number ranges and show they were consistent with that hypothesis before raising a bug report.
My guess is that such a problem, if it is the case, would not get fixed quickly, as very few people rely on this information and it would not be a trivial change to do it properly.
i’m sorry you ask me something difficult for me 
can i upload the pcap somewhere to help you diagnosis this?
Tell me if i got it:
48735 -> 48985 -> 95057
so this is this sequence number that create the problem?
in fact the problem is:
i created a small script that get this information from CLI and report me by email if the packet lost % is higher than 3%.
how can i get informations about the quality of call if i can’t use the “sip show channelstats” command?
It looks like the SSRC is unchanged. If that is really true, the peer is at fault, although I’m not sure that Asterisk will handle it well if the SSRC did change at appropriate points.
ok so i can’t rely on sip show channelstats 
currently i’m using it, but i did something dirty: if the packet lost count suddenly increase more than the number of sent packets, then i ingnore the informations.
it works, but it’s bad