[asterisk-bugs] [JIRA] (ASTERISK-26766) Asterisk 13 IAX2 jitterbuffer causes packet loss
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Sun Feb 5 15:29:10 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rusty Newton updated ASTERISK-26766:
------------------------------------
Description:
We have two quad core i7 Asterisk boxes running Fedora 24 or Fedora 25 using the vanilla Fedora compiled Asterisk 13.9.1
Between the two machines is an IAX2 trunk which is passing a small amount of SIP traffic (less than 10 calls).
When the jitterbuffer is enabled in IAX2, it causes what could be described as packet loss - the noticable result is choppy audio being heard on all phone calls.
This is not an intermittent problem - it happens to every single call that traverses the link. There are no networking switches / routers between the two machines and we have confirmed it is not a networking issue.
The issue occurs with G729 or ulaw and IAX is trunking multiple SIP calls.
There is no other processes running on the servers other than Asterisk and they are not showing any CPU loading issues.
The behavior is resolved as soon as the IAX2 jitterbuffer is turned off in iax.conf (jitterbuffer=no).
We have subsequently reverted both machines to Asterisk 11.13.1 and the bug is not present, so we believe it is a bug that has been introduced to the 13 branch.
The following iax2 show netstats shows significant Lost %:
{noformat}
calhost*CLI> iax2 show netstats
-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts FirstMsg LastMsg
IAX2/192.168.122.132:4569 3 150 204 366 32 0 530 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 1 150 190 433 33 0 630 0 1 41 10 1 0 0 0 Rx:NEW Rx:ACK
IAX2/192.168.122.132:4569 3 150 191 340 28 0 547 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 191 430 33 0 629 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 406 32 0 581 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 308 25 0 534 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 151 211 348 29 0 549 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 210 401 32 0 582 0 1 61 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 1 150 190 373 32 0 531 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 438 33 0 628 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
10 active IAX channels
{noformat}
Attached to this issue are:
1. A sample wav recording of the choppy audio being heard over the IAX2 trunk when the jitterbuffer has been enabled.
2. The iax.conf extensions.conf and sip.conf being used on the two servers to reproduce the issue
was:
We have two quad core i7 Asterisk boxes running Fedora 24 or Fedora 25 using the vanilla Fedora compiled Asterisk 13.9.1
Between the two machines is an IAX2 trunk which is passing a small amount of SIP traffic (less than 10 calls).
When the jitterbuffer is enabled in IAX2, it causes what could be described as packet loss - the noticable result is choppy audio being heard on all phone calls.
This is not an intermittent problem - it happens to every single call that traverses the link. There are no networking switches / routers between the two machines and we have confirmed it is not a networking issue.
The issue occurs with G729 or ulaw and IAX is trunking multiple SIP calls.
There is no other processes running on the servers other than Asterisk and they are not showing any CPU loading issues.
The behavior is resolved as soon as the IAX2 jitterbuffer is turned off in iax.conf (jitterbuffer=no).
We have subsequently reverted both machines to Asterisk 11.13.1 and the bug is not present, so we believe it is a bug that has been introduced to the 13 branch.
The following iax2 show netstats shows significant Lost %:
calhost*CLI> iax2 show netstats
-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts FirstMsg LastMsg
IAX2/192.168.122.132:4569 3 150 204 366 32 0 530 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 1 150 190 433 33 0 630 0 1 41 10 1 0 0 0 Rx:NEW Rx:ACK
IAX2/192.168.122.132:4569 3 150 191 340 28 0 547 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 191 430 33 0 629 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 406 32 0 581 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 308 25 0 534 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 151 211 348 29 0 549 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 210 401 32 0 582 0 1 61 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 1 150 190 373 32 0 531 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
IAX2/192.168.122.132:4569 3 150 190 438 33 0 628 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
10 active IAX channels
Attached to this issue are:
1. A sample wav recording of the choppy audio being heard over the IAX2 trunk when the jitterbuffer has been enabled.
2. The iax.conf extensions.conf and sip.conf being used on the two servers to reproduce the issue
> Asterisk 13 IAX2 jitterbuffer causes packet loss
> ------------------------------------------------
>
> Key: ASTERISK-26766
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26766
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_iax2
> Affects Versions: 13.9.1
> Environment: Fedora 25, Fedora 24
> Reporter: Kirsty Tyerman
> Attachments: 2017-02-03-11-06-04_5013-5003_eng_mf1.wav, extensions_machine1.conf, extensions_machine2.conf, iax_machine1.conf, iax_machine2.conf, sip_machine1.conf, sip_machine2.conf
>
>
> We have two quad core i7 Asterisk boxes running Fedora 24 or Fedora 25 using the vanilla Fedora compiled Asterisk 13.9.1
> Between the two machines is an IAX2 trunk which is passing a small amount of SIP traffic (less than 10 calls).
> When the jitterbuffer is enabled in IAX2, it causes what could be described as packet loss - the noticable result is choppy audio being heard on all phone calls.
> This is not an intermittent problem - it happens to every single call that traverses the link. There are no networking switches / routers between the two machines and we have confirmed it is not a networking issue.
> The issue occurs with G729 or ulaw and IAX is trunking multiple SIP calls.
> There is no other processes running on the servers other than Asterisk and they are not showing any CPU loading issues.
> The behavior is resolved as soon as the IAX2 jitterbuffer is turned off in iax.conf (jitterbuffer=no).
> We have subsequently reverted both machines to Asterisk 11.13.1 and the bug is not present, so we believe it is a bug that has been introduced to the 13 branch.
> The following iax2 show netstats shows significant Lost %:
> {noformat}
> calhost*CLI> iax2 show netstats
> -------- LOCAL --------------------- -------- REMOTE --------------------
> Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts FirstMsg LastMsg
> IAX2/192.168.122.132:4569 3 150 204 366 32 0 530 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 1 150 190 433 33 0 630 0 1 41 10 1 0 0 0 Rx:NEW Rx:ACK
> IAX2/192.168.122.132:4569 3 150 191 340 28 0 547 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 150 191 430 33 0 629 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 150 190 406 32 0 581 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 150 190 308 25 0 534 0 1 60 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 151 211 348 29 0 549 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 150 210 401 32 0 582 0 1 61 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 1 150 190 373 32 0 531 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
> IAX2/192.168.122.132:4569 3 150 190 438 33 0 628 0 1 41 10 1 0 0 0 Rx:NEW Tx:ACK
> 10 active IAX channels
> {noformat}
> Attached to this issue are:
> 1. A sample wav recording of the choppy audio being heard over the IAX2 trunk when the jitterbuffer has been enabled.
> 2. The iax.conf extensions.conf and sip.conf being used on the two servers to reproduce the issue
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list