Wrong information on sip show channelstats


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 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 67a6c04e225 00:00:27 0000001318 0000042135 (96.97%) 0.0000 0000001318 0000000000 ( 0.00%) 0.0003

i’m running with Asterisk

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 i’ll do

OK Here is the debug result: 38585f395cf 00:00:27 0000001269 0000028284 (95.71%) 0.0000 0000001254 0000000000 ( 0.00%) 0.0002

Got RTCP from

  • Sent RTCP SR to
    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. 1e9738ac161 00:01:47 0000003060 0000045754 (93.73%) 0.0000 0000003066 0000000000 ( 0.00%) 0.0001

so, here, the IPBX ( 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 :smile:

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 :frowning:

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 :smile: