RTP / RTCP data show strange values with Yealink Phone

Here is the situation, I have a Yealink T32G, and on the other side of the internet (obviously thrugh a router etc) to an Asterisk box.

If im in a call, go “sip show channelstats” i get this:

Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter XX.XXX.X.XXX 1359894543@ 0000000794 0000000000 ( 0.00%) 0.0000 0000000804 0016768943 (2085689.43%) 0.0157
Most odd that the phone reports more packets lost than where even sent. I am assuming that its up to the phone to send back the report of how many packets it got… right. Since UDP doesn’t know that its packets where received without some form of report-back, correct?

In my research i found the NTP and the time is important - really? how so? Wouldn’t it be more “count the packets received and report back

Is this just a Yealink phone thing? It is sending RTCP reports, i can see this by enabling debugging - they just seem to be plain wrong.

Doing the same thing with Blink gives a realistic result. (i.e. some loss like a packet or 2 over a long call)

Is there something i have to do or enable on the Yealink?

The calculation is supposed to be made based on missing packet sequence numbers. It could also be based on timestamps (which should go up by 20ms a time.

At least some versions of Asterisk don’t change SSRC when the source and therefore the sequence numbers and timestamps jump. They set the marker bit, but that only indicates a suitable place to adjust the latency buffer, not an actual source change.

In another test I saw this:

Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
41.221.6.226     01ab92195a8  00:08:06 0000000000  0000000000 ( 0.00%) 0.0000 0000000000  0000000000 ( 0.00%) 0.0000
41.221.6.229     1651604894@  00:08:06 0000000000  0000000000 ( 0.00%) 0.0000 0000000000  0000000000 ( 0.00%) 0.0000
2 active SIP channels

So now the call shows 8 minutes long with no packets sent or received.

I remember reading in a very old post something about P2P bridged calls that are not reported here. This call is a SIP to SIP call, and both legs have the same codec - so no transcoding. Does that qualify it as a Packet-to-Packet Bridge call? Is it still the case the P2P calls are not reported on here? This version of Asterisk is 1.8.2XX

External bridging won’t be recorded, as the RTCP will bypass Asterisk. I would have thought that packet to packet bridging would be recorded.

You don’t have any contra-indications for external bridging, but you haven’t covered all the conditions. sip show channel will tell you if you actually have it, and log entries will also indicate it.

[quote=“david55”]External bridging won’t be recorded, as the RTCP will bypass Asterisk. I would have thought that packet to packet bridging would be recorded.
[/quote]

Its not bridged externally, can-reinvite or direct media is off, NAT is on and jitter buffer is on.

This is from: voip-info.org/wiki/view/Asterisk+RTCP

[quote]
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).[/quote] But this is way old… whats the latest on RTCP?