[asterisk-bugs] [JIRA] (ASTERISK-28379) PJSIP show channelstats incorrect information output
Vyrva Igor (JIRA)
noreply at issues.asterisk.org
Wed Apr 10 08:29:47 CDT 2019
Vyrva Igor created ASTERISK-28379:
-------------------------------------
Summary: 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.3.0, 16.2.1, 16.1.1, 16.0.1
Environment: CentOS 7 (7.6.1810)
Kernel (4.20.3-1.el7.elrepo.x86_64)
Asterisk 16 (16.3.0)
Reporter: Vyrva Igor
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