[asterisk-bugs] [JIRA] (ASTERISK-28379) PJSIP show channelstats incorrect information output
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Wed Apr 10 08:29:47 CDT 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246849#comment-246849 ]
Asterisk Team commented on ASTERISK-28379:
------------------------------------------
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.
> PJSIP show channelstats incorrect information output
> ----------------------------------------------------
>
> Key: ASTERISK-28379
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28379
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_pjsip
> Affects Versions: 16.0.1, 16.1.1, 16.2.1, 16.3.0
> Environment: CentOS 7 (7.6.1810)
> Kernel (4.20.3-1.el7.elrepo.x86_64)
> Asterisk 16 (16.3.0)
> Reporter: Vyrva Igor
> Labels: pjsip
>
> 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 at 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
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list