[asterisk-bugs] [JIRA] (ASTERISK-28379) pjsip: show channelstats incorrect information output
Vyrva Igor (JIRA)
noreply at issues.asterisk.org
Wed Apr 10 09:25:47 CDT 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246851#comment-246851 ]
Vyrva Igor commented on ASTERISK-28379:
---------------------------------------
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
> 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
> Severity: Minor
> 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