Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2019-05-25 19:50:52
|
Hi Bill, > On May 25, 2019, at 1:28 PM, Bill Lewis <wr...@gm...> wrote: > > > Thank you, Lonnie, for those changes. > > Now that I've gotten farther, I find that these are similarly affected: > > https://www.fossil-scm.org/fossil/uv/fossil-src-2.5.tar.gz Yea, Fossil removed many of their older versions, I'll do the same build fix there ... we can look at updating the fossil version at some point as well. > http://www.ch-werner.de/sqliteodbc/sqliteodbc-0.9996.tar.gz This was a temporary problem, the www.ch-werner.de server is fixed so it now works. # curl -sS http://www.ch-werner.de/sqliteodbc/sqliteodbc-0.9996.tar.gz | sha1sum 505aa746d40cd381591a18046d90c209ccfc2c7a - # curl https://s3.amazonaws.com/files.astlinux-project/sqliteodbc-0.9996.tar.gz.sha1 505aa746d40cd381591a18046d90c209ccfc2c7a dl/sqliteodbc-0.9996.tar.gz Thanks for testing a clean build (empty dl/ directory) ... David Kerr tested this not long ago, so some of these must have just cropped-up. Lonnie > > Bill > > On 5/25/2019 11:35 AM, Lonnie Abelbeck wrote: >> Hi Bill, >> Thanks for the report. >> Yes, upstream download repo's can change and make our safety check trigger. Only new clean installs from source does the "changed" upstream download get noticed since previous local dl/ versions are OK. >> For libelf-0.8.12.tar.gz: >> -- >> # curl -LI http://www.mr511.de/software/libelf-0.8.12.tar.gz >> HTTP/1.1 302 Moved Temporarily >> Server: nginx >> Date: Sat, 25 May 2019 14:44:18 GMT >> Content-Type: text/html >> Content-Length: 154 >> Connection: keep-alive >> Location: http://leere.seite >> curl: (6) Could not resolve host: leere.seite (empty.page in German) >> -- >> so the upstream URL no longer works. >> But, libelf was only needed for Asterisk in the past, and it does not look like it is needed anymore ... I'll look into cleaning up that requirement. >> I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. >> https://github.com/astlinux-project/astlinux/commit/b5b5f091b04a49f420b8d30762e7ace43990b83e >> For jpegsrc.v9c.tar.gz: >> -- >> # curl -LI http://www.ijg.org/files/jpegsrc.v9c.tar.gz >> HTTP/1.1 200 OK >> Date: Sat, 25 May 2019 14:59:59 GMT >> Content-Type: application/x-gzip >> Content-Length: 1028134 >> Last-Modified: Tue, 27 Mar 2018 14:37:34 GMT >> # curl -LI https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz >> HTTP/1.1 200 OK >> Last-Modified: Sat, 27 Jan 2018 20:50:57 GMT >> Content-Type: application/x-gzip >> Content-Length: 1028200 >> So upstream is newer and 66 bytes smaller. >> Performing a diff, the upstream removed a ".directory" file, everything else is the same. >> I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. >> https://github.com/astlinux-project/astlinux/commit/ebf06efcb1880cf3ab13ed4d4833e032cbf5c624 >> Thanks again for the report. >> Lonnie >>> On May 25, 2019, at 9:24 AM, Bill Lewis <wr...@gm...> wrote: >>> >>> I've checked out the latest from https://github.com/astlinux-project/astlinux >>> >>> When I do the build, I run into a few problem with the sha1 checksums >>> not matching. For example: jpegsrc.v9c.tar.gz and libelf-0.8.12.tar.gz >>> >>> The file http://www.ijg.org/files/jpegsrc.v9c.tar.gz has sh1sum >>> 2ce111c8c0ac828a44b13ad28c265e954a342d07 >>> >>> The contents of https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 are >>> >>> cd40526843a44c69bf88b6cc462a3e0359f69d27 >>> >>> Any ideas what's up? >>> >>> Thanks, >>> Bill >>> >>> >>> SVN revision info: >>> bill@debian-60GB:~/astlinux$ svn info >>> Path: . >>> Working Copy Root Path: /home/bill/astlinux >>> URL: https://github.com/astlinux-project/astlinux.git >>> Relative URL: ^/ >>> Repository Root: https://github.com/astlinux-project/astlinux.git >>> Repository UUID: 67a1e38b-c451-6360-d8b2-ce57b7db7bff >>> Revision: 4202 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: lonnie.abelbeck >>> Last Changed Rev: 4202 >>> Last Changed Date: 2019-05-19 11:24:36 -0400 (Sun, 19 May 2019) >>> >>> >>> Output from the build: >>> >>>>>> jpeg 9c Downloading >>> --2019-05-24 08:01:41-- http://www.ijg.org/files/jpegsrc.v9c.tar.gz >>> Resolving www.ijg.org (www.ijg.org)... 104.24.122.172, 104.24.123.172, 2606:4700:30::6818:7bac, ... >>> Connecting to www.ijg.org (www.ijg.org)|104.24.122.172|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 1028134 (1004K) [application/x-gzip] >>> Saving to: ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ >>> >>> /home/bill/astlinux/tru 100%[=================================>] 1004K 5.32MB/s in 0.2s >>> >>> 2019-05-24 08:01:41 (5.32 MB/s) - ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ saved [1028134/1028134] >>> >>> 2019-05-24 08:01:41 URL:https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 [64/64] -> "dl/jpegsrc.v9c.tar.gz.sha1" [1] >>> jpegsrc.v9c.tar.gz failed verification - exiting >>> ## >>> ## Maintainer upload command: ./scripts/upload-dl-pair dl/jpegsrc.v9c.tar.gz >>> ## >>> package/Makefile.package.in:232: recipe for target '/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded' failed >>> make: *** [/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded] Error 1 >>> >>> --- >>> >>>>>> libelf 0.8.12 Downloading >>> --2019-05-25 10:19:41-- http://www.mr511.de/software//libelf-0.8.12.tar.gz >>> Resolving www.mr511.de (www.mr511.de)... 80.67.16.8, 2a00:1158:0:100::14 >>> Connecting to www.mr511.de (www.mr511.de)|80.67.16.8|:80... connected. >>> HTTP request sent, awaiting response... 302 Moved Temporarily >>> Location: http://leere.seite [following] >>> --2019-05-25 10:19:42-- http://leere.seite/ >>> Resolving leere.seite (leere.seite)... 92.242.140.21 >>> Connecting to leere.seite (leere.seite)|92.242.140.21|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: unspecified [text/html] >>> Saving to: ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ >>> >>> /home/bill/astlinux/tru [ <=> ] 872 --.-KB/s in 0s >>> >>> 2019-05-25 10:19:42 (105 MB/s) - ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ saved [872] >>> >>> 2019-05-25 10:19:42 URL:https://s3.amazonaws.com/files.astlinux-project/libelf-0.8.12.tar.gz.sha1 [66/66] -> "dl/libelf-0.8.12.tar.gz.sha1" [1] >>> libelf-0.8.12.tar.gz failed verification - exiting > > |
|
From: Bill L. <wr...@gm...> - 2019-05-25 18:28:32
|
Thank you, Lonnie, for those changes. Now that I've gotten farther, I find that these are similarly affected: https://www.fossil-scm.org/fossil/uv/fossil-src-2.5.tar.gz http://www.ch-werner.de/sqliteodbc/sqliteodbc-0.9996.tar.gz Bill On 5/25/2019 11:35 AM, Lonnie Abelbeck wrote: > Hi Bill, > > Thanks for the report. > > Yes, upstream download repo's can change and make our safety check trigger. Only new clean installs from source does the "changed" upstream download get noticed since previous local dl/ versions are OK. > > For libelf-0.8.12.tar.gz: > -- > # curl -LI http://www.mr511.de/software/libelf-0.8.12.tar.gz > HTTP/1.1 302 Moved Temporarily > Server: nginx > Date: Sat, 25 May 2019 14:44:18 GMT > Content-Type: text/html > Content-Length: 154 > Connection: keep-alive > Location: http://leere.seite > > curl: (6) Could not resolve host: leere.seite (empty.page in German) > -- > so the upstream URL no longer works. > > But, libelf was only needed for Asterisk in the past, and it does not look like it is needed anymore ... I'll look into cleaning up that requirement. > > I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. > https://github.com/astlinux-project/astlinux/commit/b5b5f091b04a49f420b8d30762e7ace43990b83e > > > For jpegsrc.v9c.tar.gz: > -- > # curl -LI http://www.ijg.org/files/jpegsrc.v9c.tar.gz > HTTP/1.1 200 OK > Date: Sat, 25 May 2019 14:59:59 GMT > Content-Type: application/x-gzip > Content-Length: 1028134 > Last-Modified: Tue, 27 Mar 2018 14:37:34 GMT > > # curl -LI https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz > HTTP/1.1 200 OK > Last-Modified: Sat, 27 Jan 2018 20:50:57 GMT > Content-Type: application/x-gzip > Content-Length: 1028200 > > So upstream is newer and 66 bytes smaller. > > Performing a diff, the upstream removed a ".directory" file, everything else is the same. > > I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. > https://github.com/astlinux-project/astlinux/commit/ebf06efcb1880cf3ab13ed4d4833e032cbf5c624 > > Thanks again for the report. > > Lonnie > > > >> On May 25, 2019, at 9:24 AM, Bill Lewis <wr...@gm...> wrote: >> >> I've checked out the latest from https://github.com/astlinux-project/astlinux >> >> When I do the build, I run into a few problem with the sha1 checksums >> not matching. For example: jpegsrc.v9c.tar.gz and libelf-0.8.12.tar.gz >> >> The file http://www.ijg.org/files/jpegsrc.v9c.tar.gz has sh1sum >> 2ce111c8c0ac828a44b13ad28c265e954a342d07 >> >> The contents of https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 are >> >> cd40526843a44c69bf88b6cc462a3e0359f69d27 >> >> Any ideas what's up? >> >> Thanks, >> Bill >> >> >> SVN revision info: >> bill@debian-60GB:~/astlinux$ svn info >> Path: . >> Working Copy Root Path: /home/bill/astlinux >> URL: https://github.com/astlinux-project/astlinux.git >> Relative URL: ^/ >> Repository Root: https://github.com/astlinux-project/astlinux.git >> Repository UUID: 67a1e38b-c451-6360-d8b2-ce57b7db7bff >> Revision: 4202 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: lonnie.abelbeck >> Last Changed Rev: 4202 >> Last Changed Date: 2019-05-19 11:24:36 -0400 (Sun, 19 May 2019) >> >> >> Output from the build: >> >>>>> jpeg 9c Downloading >> --2019-05-24 08:01:41-- http://www.ijg.org/files/jpegsrc.v9c.tar.gz >> Resolving www.ijg.org (www.ijg.org)... 104.24.122.172, 104.24.123.172, 2606:4700:30::6818:7bac, ... >> Connecting to www.ijg.org (www.ijg.org)|104.24.122.172|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 1028134 (1004K) [application/x-gzip] >> Saving to: ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ >> >> /home/bill/astlinux/tru 100%[=================================>] 1004K 5.32MB/s in 0.2s >> >> 2019-05-24 08:01:41 (5.32 MB/s) - ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ saved [1028134/1028134] >> >> 2019-05-24 08:01:41 URL:https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 [64/64] -> "dl/jpegsrc.v9c.tar.gz.sha1" [1] >> jpegsrc.v9c.tar.gz failed verification - exiting >> ## >> ## Maintainer upload command: ./scripts/upload-dl-pair dl/jpegsrc.v9c.tar.gz >> ## >> package/Makefile.package.in:232: recipe for target '/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded' failed >> make: *** [/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded] Error 1 >> >> --- >> >>>>> libelf 0.8.12 Downloading >> --2019-05-25 10:19:41-- http://www.mr511.de/software//libelf-0.8.12.tar.gz >> Resolving www.mr511.de (www.mr511.de)... 80.67.16.8, 2a00:1158:0:100::14 >> Connecting to www.mr511.de (www.mr511.de)|80.67.16.8|:80... connected. >> HTTP request sent, awaiting response... 302 Moved Temporarily >> Location: http://leere.seite [following] >> --2019-05-25 10:19:42-- http://leere.seite/ >> Resolving leere.seite (leere.seite)... 92.242.140.21 >> Connecting to leere.seite (leere.seite)|92.242.140.21|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: unspecified [text/html] >> Saving to: ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ >> >> /home/bill/astlinux/tru [ <=> ] 872 --.-KB/s in 0s >> >> 2019-05-25 10:19:42 (105 MB/s) - ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ saved [872] >> >> 2019-05-25 10:19:42 URL:https://s3.amazonaws.com/files.astlinux-project/libelf-0.8.12.tar.gz.sha1 [66/66] -> "dl/libelf-0.8.12.tar.gz.sha1" [1] >> libelf-0.8.12.tar.gz failed verification - exiting |
|
From: Lonnie A. <li...@lo...> - 2019-05-25 15:35:18
|
Hi Bill, Thanks for the report. Yes, upstream download repo's can change and make our safety check trigger. Only new clean installs from source does the "changed" upstream download get noticed since previous local dl/ versions are OK. For libelf-0.8.12.tar.gz: -- # curl -LI http://www.mr511.de/software/libelf-0.8.12.tar.gz HTTP/1.1 302 Moved Temporarily Server: nginx Date: Sat, 25 May 2019 14:44:18 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Location: http://leere.seite curl: (6) Could not resolve host: leere.seite (empty.page in German) -- so the upstream URL no longer works. But, libelf was only needed for Asterisk in the past, and it does not look like it is needed anymore ... I'll look into cleaning up that requirement. I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. https://github.com/astlinux-project/astlinux/commit/b5b5f091b04a49f420b8d30762e7ace43990b83e For jpegsrc.v9c.tar.gz: -- # curl -LI http://www.ijg.org/files/jpegsrc.v9c.tar.gz HTTP/1.1 200 OK Date: Sat, 25 May 2019 14:59:59 GMT Content-Type: application/x-gzip Content-Length: 1028134 Last-Modified: Tue, 27 Mar 2018 14:37:34 GMT # curl -LI https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz HTTP/1.1 200 OK Last-Modified: Sat, 27 Jan 2018 20:50:57 GMT Content-Type: application/x-gzip Content-Length: 1028200 So upstream is newer and 66 bytes smaller. Performing a diff, the upstream removed a ".directory" file, everything else is the same. I'll fix this by switching to our https://s3.amazonaws.com/files.astlinux-project URL for now. https://github.com/astlinux-project/astlinux/commit/ebf06efcb1880cf3ab13ed4d4833e032cbf5c624 Thanks again for the report. Lonnie > On May 25, 2019, at 9:24 AM, Bill Lewis <wr...@gm...> wrote: > > I've checked out the latest from https://github.com/astlinux-project/astlinux > > When I do the build, I run into a few problem with the sha1 checksums > not matching. For example: jpegsrc.v9c.tar.gz and libelf-0.8.12.tar.gz > > The file http://www.ijg.org/files/jpegsrc.v9c.tar.gz has sh1sum > 2ce111c8c0ac828a44b13ad28c265e954a342d07 > > The contents of https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 are > > cd40526843a44c69bf88b6cc462a3e0359f69d27 > > Any ideas what's up? > > Thanks, > Bill > > > SVN revision info: > bill@debian-60GB:~/astlinux$ svn info > Path: . > Working Copy Root Path: /home/bill/astlinux > URL: https://github.com/astlinux-project/astlinux.git > Relative URL: ^/ > Repository Root: https://github.com/astlinux-project/astlinux.git > Repository UUID: 67a1e38b-c451-6360-d8b2-ce57b7db7bff > Revision: 4202 > Node Kind: directory > Schedule: normal > Last Changed Author: lonnie.abelbeck > Last Changed Rev: 4202 > Last Changed Date: 2019-05-19 11:24:36 -0400 (Sun, 19 May 2019) > > > Output from the build: > > >>> jpeg 9c Downloading > --2019-05-24 08:01:41-- http://www.ijg.org/files/jpegsrc.v9c.tar.gz > Resolving www.ijg.org (www.ijg.org)... 104.24.122.172, 104.24.123.172, 2606:4700:30::6818:7bac, ... > Connecting to www.ijg.org (www.ijg.org)|104.24.122.172|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1028134 (1004K) [application/x-gzip] > Saving to: ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ > > /home/bill/astlinux/tru 100%[=================================>] 1004K 5.32MB/s in 0.2s > > 2019-05-24 08:01:41 (5.32 MB/s) - ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ saved [1028134/1028134] > > 2019-05-24 08:01:41 URL:https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 [64/64] -> "dl/jpegsrc.v9c.tar.gz.sha1" [1] > jpegsrc.v9c.tar.gz failed verification - exiting > ## > ## Maintainer upload command: ./scripts/upload-dl-pair dl/jpegsrc.v9c.tar.gz > ## > package/Makefile.package.in:232: recipe for target '/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded' failed > make: *** [/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded] Error 1 > > --- > > >>> libelf 0.8.12 Downloading > --2019-05-25 10:19:41-- http://www.mr511.de/software//libelf-0.8.12.tar.gz > Resolving www.mr511.de (www.mr511.de)... 80.67.16.8, 2a00:1158:0:100::14 > Connecting to www.mr511.de (www.mr511.de)|80.67.16.8|:80... connected. > HTTP request sent, awaiting response... 302 Moved Temporarily > Location: http://leere.seite [following] > --2019-05-25 10:19:42-- http://leere.seite/ > Resolving leere.seite (leere.seite)... 92.242.140.21 > Connecting to leere.seite (leere.seite)|92.242.140.21|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/html] > Saving to: ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ > > /home/bill/astlinux/tru [ <=> ] 872 --.-KB/s in 0s > > 2019-05-25 10:19:42 (105 MB/s) - ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ saved [872] > > 2019-05-25 10:19:42 URL:https://s3.amazonaws.com/files.astlinux-project/libelf-0.8.12.tar.gz.sha1 [66/66] -> "dl/libelf-0.8.12.tar.gz.sha1" [1] > libelf-0.8.12.tar.gz failed verification - exiting > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Bill L. <wr...@gm...> - 2019-05-25 14:24:48
|
I've checked out the latest from https://github.com/astlinux-project/astlinux When I do the build, I run into a few problem with the sha1 checksums not matching. For example: jpegsrc.v9c.tar.gz and libelf-0.8.12.tar.gz The file http://www.ijg.org/files/jpegsrc.v9c.tar.gz has sh1sum 2ce111c8c0ac828a44b13ad28c265e954a342d07 The contents of https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 are cd40526843a44c69bf88b6cc462a3e0359f69d27 Any ideas what's up? Thanks, Bill SVN revision info: bill@debian-60GB:~/astlinux$ svn info Path: . Working Copy Root Path: /home/bill/astlinux URL: https://github.com/astlinux-project/astlinux.git Relative URL: ^/ Repository Root: https://github.com/astlinux-project/astlinux.git Repository UUID: 67a1e38b-c451-6360-d8b2-ce57b7db7bff Revision: 4202 Node Kind: directory Schedule: normal Last Changed Author: lonnie.abelbeck Last Changed Rev: 4202 Last Changed Date: 2019-05-19 11:24:36 -0400 (Sun, 19 May 2019) Output from the build: >>> jpeg 9c Downloading --2019-05-24 08:01:41-- http://www.ijg.org/files/jpegsrc.v9c.tar.gz Resolving www.ijg.org (www.ijg.org)... 104.24.122.172, 104.24.123.172, 2606:4700:30::6818:7bac, ... Connecting to www.ijg.org (www.ijg.org)|104.24.122.172|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1028134 (1004K) [application/x-gzip] Saving to: ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ /home/bill/astlinux/tru 100%[=================================>] 1004K 5.32MB/s in 0.2s 2019-05-24 08:01:41 (5.32 MB/s) - ‘/home/bill/astlinux/trunk/dl/jpegsrc.v9c.tar.gz’ saved [1028134/1028134] 2019-05-24 08:01:41 URL:https://s3.amazonaws.com/files.astlinux-project/jpegsrc.v9c.tar.gz.sha1 [64/64] -> "dl/jpegsrc.v9c.tar.gz.sha1" [1] jpegsrc.v9c.tar.gz failed verification - exiting ## ## Maintainer upload command: ./scripts/upload-dl-pair dl/jpegsrc.v9c.tar.gz ## package/Makefile.package.in:232: recipe for target '/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded' failed make: *** [/home/bill/astlinux/trunk/output/build/jpeg-9c/.stamp_downloaded] Error 1 --- >>> libelf 0.8.12 Downloading --2019-05-25 10:19:41-- http://www.mr511.de/software//libelf-0.8.12.tar.gz Resolving www.mr511.de (www.mr511.de)... 80.67.16.8, 2a00:1158:0:100::14 Connecting to www.mr511.de (www.mr511.de)|80.67.16.8|:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: http://leere.seite [following] --2019-05-25 10:19:42-- http://leere.seite/ Resolving leere.seite (leere.seite)... 92.242.140.21 Connecting to leere.seite (leere.seite)|92.242.140.21|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ /home/bill/astlinux/tru [ <=> ] 872 --.-KB/s in 0s 2019-05-25 10:19:42 (105 MB/s) - ‘/home/bill/astlinux/trunk/dl/libelf-0.8.12.tar.gz’ saved [872] 2019-05-25 10:19:42 URL:https://s3.amazonaws.com/files.astlinux-project/libelf-0.8.12.tar.gz.sha1 [66/66] -> "dl/libelf-0.8.12.tar.gz.sha1" [1] libelf-0.8.12.tar.gz failed verification - exiting |
|
From: Michael K. <mic...@ip...> - 2019-05-13 20:15:13
|
Thanks Lonnie. Great to know the release schedule.
I will begin testing with the beta release of 1.3.6 ast13SE as this is the release train I wish to move forward with. I have a bit to do still so good to start testing now.
Thanks so much.
Regards
Michael Knill
On 14/5/19, 5:31 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Just to be clear, the next AstLinux release will be 1.3.6, and it will contain three Asterisk versions:
-- Asterisk 13.23.1 (ast13se) more tested, built --without-pjproject
-- Latest Asterisk 13.x (ast13)
-- Latest Asterisk 16.x (ast16)
> I was just wondering what the official release date of 1.3.6 is?
While releases are typically 3-4 months (1.3.6 would imply June'ish) we tag releases after package updates have stabilized and we have had sufficient time to test. So no official calendar schedule.
Can you test with Pre-Releases https://www.astlinux-project.org/dev.html using the URL:
https://s3.amazonaws.com/beta.astlinux-project/ast13se-firmware-1.x
then adding your custom code and then easily upgrading to the official 1.3.6 ast13se version in the near future?
Lonnie
> On May 13, 2019, at 1:35 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Guys
>
> Yes I know I need to roll my own some day (frankly I just don't have the time), however I was just wondering what the official release date of 1.3.6SE is?
> Reason is that I really need to get my new release out ASAP and I need to make a decision whether it will be on 1.3.4 or 1.3.6SE (preferred obviously).
>
> Thanks all.
>
> Regards
> Michael Knill
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-05-13 19:31:51
|
Hi Michael, Just to be clear, the next AstLinux release will be 1.3.6, and it will contain three Asterisk versions: -- Asterisk 13.23.1 (ast13se) more tested, built --without-pjproject -- Latest Asterisk 13.x (ast13) -- Latest Asterisk 16.x (ast16) > I was just wondering what the official release date of 1.3.6 is? While releases are typically 3-4 months (1.3.6 would imply June'ish) we tag releases after package updates have stabilized and we have had sufficient time to test. So no official calendar schedule. Can you test with Pre-Releases https://www.astlinux-project.org/dev.html using the URL: https://s3.amazonaws.com/beta.astlinux-project/ast13se-firmware-1.x then adding your custom code and then easily upgrading to the official 1.3.6 ast13se version in the near future? Lonnie > On May 13, 2019, at 1:35 PM, Michael Knill <mic...@ip...> wrote: > > Hi Guys > > Yes I know I need to roll my own some day (frankly I just don't have the time), however I was just wondering what the official release date of 1.3.6SE is? > Reason is that I really need to get my new release out ASAP and I need to make a decision whether it will be on 1.3.4 or 1.3.6SE (preferred obviously). > > Thanks all. > > Regards > Michael Knill |
|
From: Michael K. <mic...@ip...> - 2019-05-13 18:35:26
|
Hi Guys Yes I know I need to roll my own some day (frankly I just don't have the time), however I was just wondering what the official release date of 1.3.6SE is? Reason is that I really need to get my new release out ASAP and I need to make a decision whether it will be on 1.3.4 or 1.3.6SE (preferred obviously). Thanks all. Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2019-04-27 23:11:01
|
Thanks for the report, Michael. Asterisk 13.23.1 appears to be a solid choice. Lonnie > On Apr 27, 2019, at 5:25 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > I can confirm that after 5 days in the lab, the AMI: VoicemailRefresh is still working fine on Asterisk 13.23.1. > > Regards > Michael Knill > > On 23/4/19, 7:33 am, "Michael Knill" <mic...@ip...> wrote: > > Hi Devs > > Ok I am doing some more testing as I want to get this sorted. > I have now reverted to Asterisk 13.23.1 and have removed mailbox polling in voicemail.conf. > Surprisingly AMI: VoicemailRefresh IS WORKING after all! > What I am suspecting is that it did work when I tested previously but it was just very delayed and I was assuming it was some other watchdog process changing the MWI's. I have confirmed that this is not the case e.g. I left for quite a while and there status did not change. > As such, I'm going to keep testing over the next few days and if there is no change in the time then I'm going to assume that this version is ok. If not then I'm going to need to go to 13.26.0. > > I will keep you posted. > > Regards > Michael Knill > > On 22/4/19, 10:38 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Christopher, > > Thanks much for sharing your insights. > >> a while back I built a box i call WOPR which uses a series of VMs on a rather large server... > > WOPR, I love it, great classic movie reference. > > Have you used WOPR to find a solid 13.x alternative to your old 11.x version ? Possibly Asterisk 13.23.1 ? > > Lonnie > > > > >> On Apr 22, 2019, at 6:39 AM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote: >> >> 13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6) >> >> a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports. >> >> it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data. >> >> when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"... >> >> when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems) >> >> granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself.. >> >> my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules.. >> -Christopher > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-04-27 22:25:29
|
Hi Devs
I can confirm that after 5 days in the lab, the AMI: VoicemailRefresh is still working fine on Asterisk 13.23.1.
Regards
Michael Knill
On 23/4/19, 7:33 am, "Michael Knill" <mic...@ip...> wrote:
Hi Devs
Ok I am doing some more testing as I want to get this sorted.
I have now reverted to Asterisk 13.23.1 and have removed mailbox polling in voicemail.conf.
Surprisingly AMI: VoicemailRefresh IS WORKING after all!
What I am suspecting is that it did work when I tested previously but it was just very delayed and I was assuming it was some other watchdog process changing the MWI's. I have confirmed that this is not the case e.g. I left for quite a while and there status did not change.
As such, I'm going to keep testing over the next few days and if there is no change in the time then I'm going to assume that this version is ok. If not then I'm going to need to go to 13.26.0.
I will keep you posted.
Regards
Michael Knill
On 22/4/19, 10:38 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Christopher,
Thanks much for sharing your insights.
> a while back I built a box i call WOPR which uses a series of VMs on a rather large server...
WOPR, I love it, great classic movie reference.
Have you used WOPR to find a solid 13.x alternative to your old 11.x version ? Possibly Asterisk 13.23.1 ?
Lonnie
> On Apr 22, 2019, at 6:39 AM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote:
>
> 13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6)
>
> a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports.
>
> it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data.
>
> when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"...
>
> when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems)
>
> granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself..
>
> my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules..
> -Christopher
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2019-04-22 21:32:56
|
Hi Devs
Ok I am doing some more testing as I want to get this sorted.
I have now reverted to Asterisk 13.23.1 and have removed mailbox polling in voicemail.conf.
Surprisingly AMI: VoicemailRefresh IS WORKING after all!
What I am suspecting is that it did work when I tested previously but it was just very delayed and I was assuming it was some other watchdog process changing the MWI's. I have confirmed that this is not the case e.g. I left for quite a while and there status did not change.
As such, I'm going to keep testing over the next few days and if there is no change in the time then I'm going to assume that this version is ok. If not then I'm going to need to go to 13.26.0.
I will keep you posted.
Regards
Michael Knill
On 22/4/19, 10:38 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Christopher,
Thanks much for sharing your insights.
> a while back I built a box i call WOPR which uses a series of VMs on a rather large server...
WOPR, I love it, great classic movie reference.
Have you used WOPR to find a solid 13.x alternative to your old 11.x version ? Possibly Asterisk 13.23.1 ?
Lonnie
> On Apr 22, 2019, at 6:39 AM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote:
>
> 13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6)
>
> a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports.
>
> it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data.
>
> when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"...
>
> when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems)
>
> granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself..
>
> my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules..
> -Christopher
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-04-22 12:38:27
|
Hi Christopher, Thanks much for sharing your insights. > a while back I built a box i call WOPR which uses a series of VMs on a rather large server... WOPR, I love it, great classic movie reference. Have you used WOPR to find a solid 13.x alternative to your old 11.x version ? Possibly Asterisk 13.23.1 ? Lonnie > On Apr 22, 2019, at 6:39 AM, The Cadillac Kid via Astlinux-devel <ast...@li...> wrote: > > 13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6) > > a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports. > > it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data. > > when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"... > > when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems) > > granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself.. > > my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules.. > -Christopher |
|
From: Michael K. <li...@mk...> - 2019-04-22 12:07:25
|
> Am 22.04.2019 um 13:39 schrieb The Cadillac Kid via Astlinux-devel <ast...@li...>: > > 13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6) > > a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports. > > it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data. > > when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"... > > when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems) > > granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself.. > > my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules.. > -Christopher Hi Christopher, interesting insights! Can you try to repeat your test with our latest AstLinux 13 beta-version which includes Asterisk 13.26.0 (should be on par with 16.3.0)? https://www.astlinux-project.org/dev.html And yes, there were major optimizations in Asterisk 14-16 regarding high volume systems since this video from Astricon (in fall 2017): https://www.youtube.com/watch?v=1HqoqjKbeIo This is an update from Astricon 2018: https://www.youtube.com/watch?v=fhjtKT3BHhI&list=PLighc-2vlRgTnXkZ4rc_EjQdf7NAtvFDo&index=47 At about minute 10 it gets interesting about Stasis and also app_voicemail. > On Monday, April 22, 2019, 6:53:43 AM EDT, Michael Knill <mic...@ip...> wrote: > > > Ok Triple Grrr. > > Asterisk 13.24.1 is actually broken for mailbox polling. It worked ok initially but it eventually becomes sporadic and takes ages to change. > Sorry for all the hassle with this. > I will go 1.3.6 -13SE when available. > > Regards > Michael Knill > > On 22/4/19, 2:08 pm, "Michael Knill" <mic...@ip...> wrote: > > Double Grrr. > > Polling does work fine on Asterisk 13.24.1. It must have been something else we were doing that broke it. > Really sorry all for the hassle. I think I will still go to the SE version though on my next release. > > Regards > Michael Knill > > On 22/4/19, 1:53 pm, "Michael Knill" <mic...@ip...> wrote: > > Ok you have concerned me enough to test on Asterisk 13.23.1. > Mailbox polling works great and 10 seconds is a good number. > On an APU1 there was about a 0.1% increase in CPU for a 5 extension system. > Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now. > > PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage. > > Regards > Michael Knill > > On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Michael, > > I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO. > > There may be other (bad) side-effects performing a 'voicemail reload' at random times. > > Lonnie > > > > > On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote: > > > > No I didn't actually try that but I have a sneaking suspicion it will. > > I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway. > > > > Regards > > Michael Knill > > > > On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > > > Michael, > > > > Doesn't this work in 13.23.1 ? > > -- voicemail.conf -- > > pollmailboxes = yes > > pollfreq = 10 > > -- > > > > You should not have to mess with other refresh methods, unless you are manually moving VM files around. > > > > Lonnie > > > > > >> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote: > >> > >> Thanks Lonnie > >> > >> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI. > >> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be. > >> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying. > >> > >> Were you just using the UserEvent: FOP2RELOADVOICEMAIL? > >> > >> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'. > >> PS I do like the concept of an SE variant now actually. > >> > >> Thanks > >> > >> Regards > >> Michael Knill > >> > >> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > >> > >> Hi Michael, > >> > >> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ? > >> > >> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release. > >> > >>> Does this seem reasonable? > >> > >> We need to understand this VM MWI issue(s) more. > >> > >> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues. > >> > >> Lonnie > >> > >> > >> > >>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote: > >>> > >>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release. > >>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1? > >>> Is this bad enough to defer or note for 1.3.5.2? > >>> > >>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload. > >>> > >>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred). > >>> > >>> Does this seem reasonable? > >>> > >>> Regards > >>> Michael Knill > >>> > >>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > >>> > >>> Hi Michael, > >>> > >>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? > >>> > >>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . > >>> > >>> https://www.astlinux-project.org/dev.html > >>> > >>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. > >>> > >>> Michael, when loading the voicemail module, are there any errors or warnings ? > >>> > >>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. > >>> > >>> Lonnie > >>> > >>> > >>> > >>> > >>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: > >>>> > >>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. > >>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). > >>>> > >>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. > >>>> > >>>> Any ideas where the problem could be or what I can try next? > >>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. > >>>> > >>>> Regards > >>>> Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2019-04-22 12:01:55
|
Thanks Chris for the feedback.
I think I will probably delay putting it into production.
Regards
Michael Knill
From: The Cadillac Kid via Astlinux-devel <ast...@li...>
Reply-To: AstLinux Developers Mailing List <ast...@li...>
Date: Monday, 22 April 2019 at 9:39 pm
To: AstLinux Developers Mailing List <ast...@li...>
Cc: The Cadillac Kid <eld...@ya...>
Subject: Re: [Astlinux-devel] Grrr I cant get Voicemail MWI status to refresh
13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6)
a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports.
it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data.
when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"...
when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems)
granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself..
my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules..
-Christopher
On Monday, April 22, 2019, 6:53:43 AM EDT, Michael Knill <mic...@ip...> wrote:
Ok Triple Grrr.
Asterisk 13.24.1 is actually broken for mailbox polling. It worked ok initially but it eventually becomes sporadic and takes ages to change.
Sorry for all the hassle with this.
I will go 1.3.6 -13SE when available.
Regards
Michael Knill
On 22/4/19, 2:08 pm, "Michael Knill" <mic...@ip...<mailto:mic...@ip...>> wrote:
Double Grrr.
Polling does work fine on Asterisk 13.24.1. It must have been something else we were doing that broke it.
Really sorry all for the hassle. I think I will still go to the SE version though on my next release.
Regards
Michael Knill
On 22/4/19, 1:53 pm, "Michael Knill" <mic...@ip...<mailto:mic...@ip...>> wrote:
Ok you have concerned me enough to test on Asterisk 13.23.1.
Mailbox polling works great and 10 seconds is a good number.
On an APU1 there was about a 0.1% increase in CPU for a 5 extension system.
Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now.
PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage.
Regards
Michael Knill
On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
Michael,
I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO.
There may be other (bad) side-effects performing a 'voicemail reload' at random times.
Lonnie
> On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>
> No I didn't actually try that but I have a sneaking suspicion it will.
> I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
>
> Michael,
>
> Doesn't this work in 13.23.1 ?
> -- voicemail.conf --
> pollmailboxes = yes
> pollfreq = 10
> --
>
> You should not have to mess with other refresh methods, unless you are manually moving VM files around.
>
> Lonnie
>
>
>> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>
>> Thanks Lonnie
>>
>> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
>> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
>> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>>
>> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>>
>> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
>> PS I do like the concept of an SE variant now actually.
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>>
>> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
>>
>> Hi Michael,
>>
>> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>>
>> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>>
>>> Does this seem reasonable?
>>
>> We need to understand this VM MWI issue(s) more.
>>
>> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>>
>> Lonnie
>>
>>
>>
>>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>>
>>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>>> Is this bad enough to defer or note for 1.3.5.2?
>>>
>>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>>
>>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>>
>>> Does this seem reasonable?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
>>>
>>> Hi Michael,
>>>
>>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>>
>>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>>
>>> https://www.astlinux-project.org/dev.html
>>>
>>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>>
>>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>>
>>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>>>
>>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>>
>>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>>
>>>> Any ideas where the problem could be or what I can try next?
>>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...<mailto:Ast...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...<mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...<mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...<mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...<mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...<mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...<mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: The C. K. <eld...@ya...> - 2019-04-22 11:39:40
|
13.24.1 is broken in more than one way.. I did a test run emulating one of my 2000 line production systems and found that as the mailbixes get lazier and lazier so does the dialplan.. call processing slows down.. Macros and gosubs seem to get slower and slower as the number of calls get processed and voicemails get left.. (the production sites are still running on old 11.20.6)
a while back I built a box i call WOPR which uses a series of VMs on a rather large server to emulate stations registering and placing calls on the "subject".. (a physical i7 4770k with 8 gigs ram).. scripts on aastra(mitel) 68xx series physical phones make the phones answer, place calls on hold, transfer, etc.. since audio files play, they also can leave Voicemails.. the WOPR box estensions.. answer , play RTP, hang up, xfer etc. its the best emulation of a hotel environment I could create without 100s of FXO ports wired to 100s of FXS ports.
it seems to me the more voicemails that get left on a system running 13.24.1 the slower it gets to send out MWI notifies regardless of the pollmailboxes settings.. I also run an externnotify script and some users get VM2email.. the email process is offloaded.. so the email command is simply a catcher for the email data.
when I put the bleeding edge 16 on the "subject" machine it seems the issues went away.. im not ready to put 16 on a 2000 line production yet but seems like maybe the big is "fixed"...
when I put 11.20.6 back on the subject all my issues went away (well other than the RTP port leaks and occasional chan_sip freezes that 11.20.6 had anyway on high volume systems)
granted my tests arent with astlinux as I outgrew it some time ago for production but does give some insight into asterisk itself..
my asterisk installations are "beat down".. I only compile the modules I need to use and none more.. my normal load is about 50 modules..
-Christopher
On Monday, April 22, 2019, 6:53:43 AM EDT, Michael Knill <mic...@ip...> wrote:
Ok Triple Grrr.
Asterisk 13.24.1 is actually broken for mailbox polling. It worked ok initially but it eventually becomes sporadic and takes ages to change.
Sorry for all the hassle with this.
I will go 1.3.6 -13SE when available.
Regards
Michael Knill
On 22/4/19, 2:08 pm, "Michael Knill" <mic...@ip...> wrote:
Double Grrr.
Polling does work fine on Asterisk 13.24.1. It must have been something else we were doing that broke it.
Really sorry all for the hassle. I think I will still go to the SE version though on my next release.
Regards
Michael Knill
On 22/4/19, 1:53 pm, "Michael Knill" <mic...@ip...> wrote:
Ok you have concerned me enough to test on Asterisk 13.23.1.
Mailbox polling works great and 10 seconds is a good number.
On an APU1 there was about a 0.1% increase in CPU for a 5 extension system.
Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now.
PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage.
Regards
Michael Knill
On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO.
There may be other (bad) side-effects performing a 'voicemail reload' at random times.
Lonnie
> On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote:
>
> No I didn't actually try that but I have a sneaking suspicion it will.
> I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
> Doesn't this work in 13.23.1 ?
> -- voicemail.conf --
> pollmailboxes = yes
> pollfreq = 10
> --
>
> You should not have to mess with other refresh methods, unless you are manually moving VM files around.
>
> Lonnie
>
>
>> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
>> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
>> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>>
>> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>>
>> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
>> PS I do like the concept of an SE variant now actually.
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>>
>> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>>
>> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>>
>>> Does this seem reasonable?
>>
>> We need to understand this VM MWI issue(s) more.
>>
>> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>>
>> Lonnie
>>
>>
>>
>>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>>> Is this bad enough to defer or note for 1.3.5.2?
>>>
>>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>>
>>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>>
>>> Does this seem reasonable?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> Hi Michael,
>>>
>>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>>
>>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>>
>>> https://www.astlinux-project.org/dev.html
>>>
>>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>>
>>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>>
>>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>>
>>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>>
>>>> Any ideas where the problem could be or what I can try next?
>>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <li...@mk...> - 2019-04-22 11:25:02
|
> Am 22.04.2019 um 04:19 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael, > > Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ? > > This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release. > >> Does this seem reasonable? > > We need to understand this VM MWI issue(s) more. > > I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues. > > Lonnie Update: 28340 is a duplicate of 28215, which is fixed in 13.25.0. https://issues.asterisk.org/jira/browse/ASTERISK-28340 https://issues.asterisk.org/jira/browse/ASTERISK-28215 >> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote: >> >> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release. >> Looks like it is bug 28340 which I assume will be fixed in 13.25.1? >> Is this bad enough to defer or note for 1.3.5.2? >> >> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload. >> >> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred). >> >> Does this seem reasonable? >> >> Regards >> Michael Knill >> >> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? >> >> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . >> >> https://www.astlinux-project.org/dev.html >> >> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. >> >> Michael, when loading the voicemail module, are there any errors or warnings ? >> >> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. >> >> Lonnie >> >>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: >>> >>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. >>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). >>> >>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. >>> >>> Any ideas where the problem could be or what I can try next? >>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. >>> >>> Regards >>> Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2019-04-22 10:53:35
|
Ok Triple Grrr.
Asterisk 13.24.1 is actually broken for mailbox polling. It worked ok initially but it eventually becomes sporadic and takes ages to change.
Sorry for all the hassle with this.
I will go 1.3.6 -13SE when available.
Regards
Michael Knill
On 22/4/19, 2:08 pm, "Michael Knill" <mic...@ip...> wrote:
Double Grrr.
Polling does work fine on Asterisk 13.24.1. It must have been something else we were doing that broke it.
Really sorry all for the hassle. I think I will still go to the SE version though on my next release.
Regards
Michael Knill
On 22/4/19, 1:53 pm, "Michael Knill" <mic...@ip...> wrote:
Ok you have concerned me enough to test on Asterisk 13.23.1.
Mailbox polling works great and 10 seconds is a good number.
On an APU1 there was about a 0.1% increase in CPU for a 5 extension system.
Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now.
PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage.
Regards
Michael Knill
On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO.
There may be other (bad) side-effects performing a 'voicemail reload' at random times.
Lonnie
> On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote:
>
> No I didn't actually try that but I have a sneaking suspicion it will.
> I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
> Doesn't this work in 13.23.1 ?
> -- voicemail.conf --
> pollmailboxes = yes
> pollfreq = 10
> --
>
> You should not have to mess with other refresh methods, unless you are manually moving VM files around.
>
> Lonnie
>
>
>> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
>> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
>> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>>
>> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>>
>> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
>> PS I do like the concept of an SE variant now actually.
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>>
>> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>>
>> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>>
>>> Does this seem reasonable?
>>
>> We need to understand this VM MWI issue(s) more.
>>
>> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>>
>> Lonnie
>>
>>
>>
>>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>>> Is this bad enough to defer or note for 1.3.5.2?
>>>
>>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>>
>>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>>
>>> Does this seem reasonable?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> Hi Michael,
>>>
>>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>>
>>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>>
>>> https://www.astlinux-project.org/dev.html
>>>
>>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>>
>>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>>
>>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>>
>>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>>
>>>> Any ideas where the problem could be or what I can try next?
>>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2019-04-22 04:08:42
|
Double Grrr.
Polling does work fine on Asterisk 13.24.1. It must have been something else we were doing that broke it.
Really sorry all for the hassle. I think I will still go to the SE version though on my next release.
Regards
Michael Knill
On 22/4/19, 1:53 pm, "Michael Knill" <mic...@ip...> wrote:
Ok you have concerned me enough to test on Asterisk 13.23.1.
Mailbox polling works great and 10 seconds is a good number.
On an APU1 there was about a 0.1% increase in CPU for a 5 extension system.
Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now.
PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage.
Regards
Michael Knill
On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO.
There may be other (bad) side-effects performing a 'voicemail reload' at random times.
Lonnie
> On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote:
>
> No I didn't actually try that but I have a sneaking suspicion it will.
> I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
> Doesn't this work in 13.23.1 ?
> -- voicemail.conf --
> pollmailboxes = yes
> pollfreq = 10
> --
>
> You should not have to mess with other refresh methods, unless you are manually moving VM files around.
>
> Lonnie
>
>
>> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
>> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
>> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>>
>> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>>
>> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
>> PS I do like the concept of an SE variant now actually.
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>>
>> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>>
>> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>>
>>> Does this seem reasonable?
>>
>> We need to understand this VM MWI issue(s) more.
>>
>> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>>
>> Lonnie
>>
>>
>>
>>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>>> Is this bad enough to defer or note for 1.3.5.2?
>>>
>>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>>
>>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>>
>>> Does this seem reasonable?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> Hi Michael,
>>>
>>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>>
>>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>>
>>> https://www.astlinux-project.org/dev.html
>>>
>>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>>
>>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>>
>>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>>
>>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>>
>>>> Any ideas where the problem could be or what I can try next?
>>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2019-04-22 03:53:28
|
Ok you have concerned me enough to test on Asterisk 13.23.1.
Mailbox polling works great and 10 seconds is a good number.
On an APU1 there was about a 0.1% increase in CPU for a 5 extension system.
Yes I'm getting too concerned about resource usage, especially considering the grunty boxes we are installing now.
PS just for fun I changed it to 1 second and frankly I didn't see much difference in CPU usage.
Regards
Michael Knill
On 22/4/19, 1:08 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO.
There may be other (bad) side-effects performing a 'voicemail reload' at random times.
Lonnie
> On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote:
>
> No I didn't actually try that but I have a sneaking suspicion it will.
> I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Michael,
>
> Doesn't this work in 13.23.1 ?
> -- voicemail.conf --
> pollmailboxes = yes
> pollfreq = 10
> --
>
> You should not have to mess with other refresh methods, unless you are manually moving VM files around.
>
> Lonnie
>
>
>> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Thanks Lonnie
>>
>> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
>> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
>> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>>
>> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>>
>> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
>> PS I do like the concept of an SE variant now actually.
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>>
>> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>>
>> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>>
>>> Does this seem reasonable?
>>
>> We need to understand this VM MWI issue(s) more.
>>
>> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>>
>> Lonnie
>>
>>
>>
>>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>>> Is this bad enough to defer or note for 1.3.5.2?
>>>
>>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>>
>>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>>
>>> Does this seem reasonable?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>
>>> Hi Michael,
>>>
>>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>>
>>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>>
>>> https://www.astlinux-project.org/dev.html
>>>
>>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>>
>>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>>
>>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>>>
>>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>>
>>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>>
>>>> Any ideas where the problem could be or what I can try next?
>>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>>
>>>> Regards
>>>> Michael Knill
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-04-22 03:08:03
|
Michael, I would suggest not doing a 'voicemail reload' and rely on pollmailboxes/pollfreq, IMO. There may be other (bad) side-effects performing a 'voicemail reload' at random times. Lonnie > On Apr 21, 2019, at 10:02 PM, Michael Knill <mic...@ip...> wrote: > > No I didn't actually try that but I have a sneaking suspicion it will. > I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway. > > Regards > Michael Knill > > On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Michael, > > Doesn't this work in 13.23.1 ? > -- voicemail.conf -- > pollmailboxes = yes > pollfreq = 10 > -- > > You should not have to mess with other refresh methods, unless you are manually moving VM files around. > > Lonnie > > >> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote: >> >> Thanks Lonnie >> >> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI. >> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be. >> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying. >> >> Were you just using the UserEvent: FOP2RELOADVOICEMAIL? >> >> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'. >> PS I do like the concept of an SE variant now actually. >> >> Thanks >> >> Regards >> Michael Knill >> >> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ? >> >> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release. >> >>> Does this seem reasonable? >> >> We need to understand this VM MWI issue(s) more. >> >> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues. >> >> Lonnie >> >> >> >>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote: >>> >>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release. >>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1? >>> Is this bad enough to defer or note for 1.3.5.2? >>> >>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload. >>> >>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred). >>> >>> Does this seem reasonable? >>> >>> Regards >>> Michael Knill >>> >>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >>> >>> Hi Michael, >>> >>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? >>> >>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . >>> >>> https://www.astlinux-project.org/dev.html >>> >>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. >>> >>> Michael, when loading the voicemail module, are there any errors or warnings ? >>> >>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. >>> >>> Lonnie >>> >>> >>> >>> >>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: >>>> >>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. >>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). >>>> >>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. >>>> >>>> Any ideas where the problem could be or what I can try next? >>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. >>>> >>>> Regards >>>> Michael Knill >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-04-22 03:02:30
|
No I didn't actually try that but I have a sneaking suspicion it will.
I would actually rather do a 'voicemail reload' when I needed to with immediate status change rather than polling every 10 seconds unnecessarily though anyway.
Regards
Michael Knill
On 22/4/19, 12:46 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
Doesn't this work in 13.23.1 ?
-- voicemail.conf --
pollmailboxes = yes
pollfreq = 10
--
You should not have to mess with other refresh methods, unless you are manually moving VM files around.
Lonnie
> On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
> I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
> I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
>
> Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
>
> As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
> PS I do like the concept of an SE variant now actually.
>
> Thanks
>
> Regards
> Michael Knill
>
> On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
>
> This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
>
>> Does this seem reasonable?
>
> We need to understand this VM MWI issue(s) more.
>
> I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
>
> Lonnie
>
>
>
>> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>>
>> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
>> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
>> Is this bad enough to defer or note for 1.3.5.2?
>>
>> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>>
>> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>>
>> Does this seem reasonable?
>>
>> Regards
>> Michael Knill
>>
>> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>>
>> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>>
>> https://www.astlinux-project.org/dev.html
>>
>> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>>
>> Michael, when loading the voicemail module, are there any errors or warnings ?
>>
>> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>>
>> Lonnie
>>
>>
>>
>>
>>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>>
>>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>>
>>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>>
>>> Any ideas where the problem could be or what I can try next?
>>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>>
>>> Regards
>>> Michael Knill
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-04-22 02:46:09
|
Michael, Doesn't this work in 13.23.1 ? -- voicemail.conf -- pollmailboxes = yes pollfreq = 10 -- You should not have to mess with other refresh methods, unless you are manually moving VM files around. Lonnie > On Apr 21, 2019, at 9:36 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI. > I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be. > I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying. > > Were you just using the UserEvent: FOP2RELOADVOICEMAIL? > > As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'. > PS I do like the concept of an SE variant now actually. > > Thanks > > Regards > Michael Knill > > On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ? > > This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release. > >> Does this seem reasonable? > > We need to understand this VM MWI issue(s) more. > > I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues. > > Lonnie > > > >> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote: >> >> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release. >> Looks like it is bug 28340 which I assume will be fixed in 13.25.1? >> Is this bad enough to defer or note for 1.3.5.2? >> >> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload. >> >> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred). >> >> Does this seem reasonable? >> >> Regards >> Michael Knill >> >> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? >> >> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . >> >> https://www.astlinux-project.org/dev.html >> >> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. >> >> Michael, when loading the voicemail module, are there any errors or warnings ? >> >> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. >> >> Lonnie >> >> >> >> >>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: >>> >>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. >>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). >>> >>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. >>> >>> Any ideas where the problem could be or what I can try next? >>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. >>> >>> Regards >>> Michael Knill >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-04-22 02:36:56
|
Thanks Lonnie
Well never having used AMI: VoicemailRefresh, I don't know if it ever worked or used for something else e.g. external MWI.
I basically want to be able to perform an MWI refresh for a specific mailbox and it seems to be more difficult than it should be.
I would rather not turn on FOP to do this (although that didn't seem to work for me either). Quite annoying.
Were you just using the UserEvent: FOP2RELOADVOICEMAIL?
As it currently stands, I will be implementing 1.3.6-13se when released and doing a 'voicemail reload'.
PS I do like the concept of an SE variant now actually.
Thanks
Regards
Michael Knill
On 22/4/19, 12:20 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ?
This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release.
> Does this seem reasonable?
We need to understand this VM MWI issue(s) more.
I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues.
Lonnie
> On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote:
>
> DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
> Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
> Is this bad enough to defer or note for 1.3.5.2?
>
> In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
>
> So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
>
> Does this seem reasonable?
>
> Regards
> Michael Knill
>
> On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
>
> Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
>
> https://www.astlinux-project.org/dev.html
>
> As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
>
> Michael, when loading the voicemail module, are there any errors or warnings ?
>
> Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
>
> Lonnie
>
>
>
>
>> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>>
>> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
>> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>>
>> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>>
>> Any ideas where the problem could be or what I can try next?
>> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>>
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-04-22 02:20:04
|
Hi Michael, Good work, fortunately Asterisk 13.23.1 (13se) does not have this (28340) bug. Are you saying VM MWI still has issue in 13.23.1 (13se) ? This (28340) bug has been fixed in 13.26.0 and 16.3.0, but only available in the current Pre-Release. > Does this seem reasonable? We need to understand this VM MWI issue(s) more. I have tested Asterisk 13.23.1 and found a seeming obscure bug, but in general no issues. Lonnie > On Apr 21, 2019, at 8:15 PM, Michael Knill <mic...@ip...> wrote: > > DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release. > Looks like it is bug 28340 which I assume will be fixed in 13.25.1? > Is this bad enough to defer or note for 1.3.5.2? > > In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload. > > So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred). > > Does this seem reasonable? > > Regards > Michael Knill > > On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? > > Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . > > https://www.astlinux-project.org/dev.html > > As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. > > Michael, when loading the voicemail module, are there any errors or warnings ? > > Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. > > Lonnie > > > > >> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: >> >> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. >> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). >> >> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. >> >> Any ideas where the problem could be or what I can try next? >> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2019-04-22 01:15:21
|
DoH! I posted this on the forum and Josh responded saying it was a bug fixed in the latest release.
Looks like it is bug 28340 which I assume will be fixed in 13.25.1?
Is this bad enough to defer or note for 1.3.5.2?
In Asterisk 13.23.1 however, AMI: VoicemailRefresh still does not work still but doing a voicemail reload does refresh the status. Although this is still not great, its far more tolerable than a sip reload.
So it looks like my new release will be either 1.3.4 or 1.3.6 - 13se (preferred).
Does this seem reasonable?
Regards
Michael Knill
On 21/4/19, 11:21 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ?
Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 .
https://www.astlinux-project.org/dev.html
As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you.
Michael, when loading the voicemail module, are there any errors or warnings ?
Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead.
Lonnie
> On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote:
>
> We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time.
> I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2).
>
> I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work.
>
> Any ideas where the problem could be or what I can try next?
> The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app.
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2019-04-21 13:20:54
|
Hi Michael, Are you saying MWI eventually works (say in 30 seconds) or does it seemingly never work ? Is this Voicemail Portal basically pure AstLinux, if so you could quickly try the latest 13se pre-release with Asterisk 13.23.1 . https://www.astlinux-project.org/dev.html As it turns out Asterisk 13.24.0 had changes that caused issues with VM MWI, Michael Keuter and I spent a lot of time tracking the issue, reported to Digium and "fixed" in 13.24.1 . As such a lot of extra testing was spent wrt VM MWI before the release of Astlinux 1.3.5.2 ... it should work for you. Michael, when loading the voicemail module, are there any errors or warnings ? Look for typos, make sure pollmailboxes and pollfreq are in the [general] section of voicemail.conf . Try pollfreq=20 instead. Lonnie > On Apr 21, 2019, at 6:38 AM, Michael Knill <mic...@ip...> wrote: > > We have built a separate Voicemail Portal but frankly I cant even get the standard Astlinux Voicemail Tab refreshing the status of MWI in any reasonable amount of time. > I don't know if its something funny in Asterisk 13.24.1 (Astlinux 1.3.5.2). > > I have tried to use the AMI: VoicemailRefresh which does nothing and also setting pollmailboxes=yes and pollfreq=10 and still it does not change the MWI status on the phone for ages. I have also tried the UserEvent: FOP2RELOADVOICEMAIL and I still cant get that to work. > > Any ideas where the problem could be or what I can try next? > The only thing that seems to work is a module reload chan_sip.so but I really dont want to be doing that every time someone uses my voicemail app. > > Regards > Michael Knill > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
28 messages has been excluded from this view by a project administrator.
