[Home]

Summary:ASTERISK-28379: pjsip: show channelstats incorrect information output
Reporter:Vyrva Igor (vigor1710)Labels:pjsip
Date Opened:2019-04-10 08:28:59Date Closed:2019-05-15 17:47:58
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip
Versions:16.0.1 16.1.1 16.2.1 16.3.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment: CentOS 7 (7.6.1810) Kernel (4.20.3-1.el7.elrepo.x86_64) Asterisk 16 (16.3.0) Attachments:
Description:Problem 1:
There are oddities in the work of the team:
{noformat}
pjsip show channelstats
{noformat}
With a long conversation in "Receive" the number of losses can "jump" by a number several times higher than the number of packets themselves:
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:00:11 slin      393       0    0   0.000    405       0    0   0.000   0.031
759e4c44 pjsip-noreg-000000 00:00:11 alaw      405       0    0   0.000    393       0    0   0.002   0.000

Objects found: 2
{noformat}
Wait ~12 min
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:12:27 slin    37205       0    0   0.000  37217       0    0   0.000   0.027
759e4c44 pjsip-noreg-000000 00:12:27 alaw    37217       0    0   0.000  37205       0    0   0.001   0.000

Objects found: 2
{noformat}
Wait +2 min
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:14:34 slin    43573       0    0   0.000  43584       0    0   0.000   0.027
759e4c44 pjsip-noreg-000000 00:14:34 alaw    43584  4294901K 98394   0.000  43573       0    0   0.000   0.000

Objects found: 2
{noformat}
Wait +7 min
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:21:21 slin    63893  4294901K 67118   0.000  63890       0    0   0.000   0.026
759e4c44 pjsip-noreg-000000 00:21:21 alaw    63890  4294901K 67121   0.000  63893       0    0   0.003   0.000

Objects found: 2
{noformat}
As we have seen, packet "Receive" much less than packages "Lost" 4294901K. This suggests that these data are not true.

But if we wait a little longer, these Losses will disappear:
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:25:28 slin    76243       0    0   0.000  76240       0    0   0.000   0.026
759e4c44 pjsip-noreg-000000 00:25:28 alaw    76240       0    0   0.000  76243       0    0   0.001   0.000

Objects found: 2
{noformat}
This behavior is extremely strange for a tool that should give information about the quality of the channel

In this example, the scheme was used:
Phone 1 <-> Asterisk 14(PJSIP) <-> Asterisk 16 (PJSIP) <-> Phone 2
A similar situation if you make a call on the scheme:
Phone 1 <-> Asterisk 16 (PJSIP) <-> Phone 2

Settings:
pjsip.conf
{noformat}
[system]
type=system
timer_t1=500
timer_b=32000
compact_headers=no

[global]
type=global
debug=no

[transport-udp]
type = transport
 protocol = udp
 bind = 0.0.0.0
 allow_reload = yes

[phone-endpoint](!)
type = endpoint
 context = local
 disallow = all
 allow = ulaw,alaw
 dtmf_mode = rfc4733
 direct_media = no
 language = ru

[phone-auth](!)
type = auth
 auth_type = userpass
 password = pa$$w0rd

[phone-aor](!)
type = aor
 max_contacts = 1
 default_expiration=600
 qualify_frequency=150
 authenticate_qualify=yes

[439](phone-endpoint)
auth = 439
 aors = 439
[439](phone-auth)
username = 439
[439](phone-aor)

[pjsip-noreg]
type = endpoint
 aors = pjsip-noreg
 context = local
 contact_user = 555666
 disallow = all
 allow = alaw
 allow = ulaw
 rtp_symmetric = yes
 direct_media = no
 sdp_session = MB
 allow_subscribe = no
 allow_transfer = no
 timers = no
 asymmetric_rtp_codec = yes

[pjsip-noreg]
type = aor
 contact = sip:555555@192.168.6.66:5065
 qualify_frequency = 300
 authenticate_qualify = yes
 max_contacts = 5

[pjsip-noreg]
type = identify
 endpoint = pjsip-noreg
 match = 192.168.6.66
{noformat}
On Asterisk 14 settings similar
-----------------------------------------------------------------------------------
Problem 2:
On some Phones (as an example D-Link DPH-400SE) if you put the interlocutor on Hold, the packet counter "Receive" is reset:
{noformat}
-- Started music on hold, class 'default', on channel 'PJSIP/pjsip-noreg-0000002e'
CLI> pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:29:18 alaw    87359       0    0   0.000  87353       0    0   0.000   0.027
759e4c44 pjsip-noreg-000000 00:29:18 alaw    87768       0    0   0.000  87770       0    0   0.001   0.000

Objects found: 2

-- Stopped music on hold on PJSIP/pjsip-noreg-0000002e
CLI> pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

759e4c44 439-0000002f       00:30:07 alaw      370       0    0   0.000  87728       0    0   0.015   0.027
759e4c44 pjsip-noreg-000000 00:30:07 alaw    90222       0    0   0.000  90219       0    0   0.000   0.000

Objects found: 2
{noformat}

In this case, the call went according to the scheme:
Phone 1 <-> Asterisk 14(PJSIP) <-> Asterisk 16 (PJSIP) <-> Phone 2
And Hold turn on your Phone 2
But this happens even if on Hold to include on the Phone connected to another Asterisk:
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

abd7fe33 115-00000001       00:00:08 alaw      311       0    0   0.000    287       0    0   0.006   0.000
abd7fe33 pjsip-noreg-000000 00:00:08 alaw      287       0    0   0.000    308       0    0   0.000   0.000

Objects found: 2

pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

abd7fe33 115-00000001       00:00:18 alaw      793       0    0 169.000    767       0    0   0.006   0.020
abd7fe33 pjsip-noreg-000000 00:00:18 alaw      121       0    0   0.000    790       0    0   0.001   0.000

Objects found: 2
{noformat}
Only in this case also appear Lost in Transmit
{noformat}
pjsip show channelstats

                                            ...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
===========================================================================================================

abd7fe33 115-00000001       00:00:25 alaw     1164       0    0 155.000   1135       0    0   0.006   0.020
abd7fe33 pjsip-noreg-000000 00:00:25 alaw      273       0    0   0.000   1161   18264  1573   0.000   0.021

Objects found: 2
{noformat}

This behavior is also incorrect
Comments:By: Asterisk Team (asteriskteam) 2019-04-10 08:29:00.051-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

By: Joshua C. Colp (jcolp) 2019-04-10 08:43:22.412-0500

I think in the first case it may be possible for rollover to occur, resulting in a wrong calculation when presenting the data.
In the second case the value isn't coming from Asterisk - it's being received by Asterisk from the remote side. It's stating that there's lost packets, but that's because it has placed us on hold.

By: Vyrva Igor (vigor1710) 2019-04-10 09:25:01.614-0500

That's possible. But in the same Asterisk 14 (14.6.1) described problems are not observed, from which we can conclude that this behavior pjsip show channelstats is not correct

By: Joshua C. Colp (jcolp) 2019-04-10 09:28:31.119-0500

The CLI command is not the underlying problem but the RTCP portion is. The CLI command just retrieves the data and presents it.

By: Friendly Automation (friendly-automation) 2019-05-15 17:47:59.659-0500

Change 11366 merged by Friendly Automation:
res_rtp_asterisk: Fix sequence number cycling and packet loss count.

[https://gerrit.asterisk.org/c/asterisk/+/11366|https://gerrit.asterisk.org/c/asterisk/+/11366]

By: Friendly Automation (friendly-automation) 2019-05-15 17:50:53.697-0500

Change 11365 merged by Joshua Colp:
res_rtp_asterisk: Fix sequence number cycling and packet loss count.

[https://gerrit.asterisk.org/c/asterisk/+/11365|https://gerrit.asterisk.org/c/asterisk/+/11365]