Summary: | ASTERISK-28379: pjsip: show channelstats incorrect information output | ||
Reporter: | Vyrva Igor (vigor1710) | Labels: | pjsip |
Date Opened: | 2019-04-10 08:28:59 | Date Closed: | 2019-05-15 17:47:58 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | 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] |