[asterisk-bugs] [JIRA] (ASTERISK-28379) pjsip: show channelstats incorrect information output

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Wed May 8 10:43:47 CDT 2019


     [ https://issues.asterisk.org/jira/browse/ASTERISK-28379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on ASTERISK-28379 started by Joshua C. Colp.

> 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
>            Assignee: Joshua C. Colp
>            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