Any feedback about Wazo Platform 20.13 is welcome!
Hello @fblackburn. Installed this morning. No error during the upgrade. No concern for the moment.
It had been a while since I could use wazo-upgrade
or a wazo-service restart
without using systemctl restart
for chatd
and calld
. Good job !
Adrien
Upgraded a system to 20.14 from 20.03, experienced the following two challenges, checking if these are known and if others experienced similar or this is an anomoly:
-
Incoming calls no longer accepted - was already configured in pjsip, outgoing calls operated as before but internal calls were not processed. Incoming trunk calls were met with a 401 Unauthorized message. Adding a “match” parameter with a comma separated list of the incoming IP addresses for the trunks resolved the issue.
-
Ring groups no longer play ring, but music - Even though musicclass is set to None in queues.conf, external caller is met with music instead of the ringing. Recreating ring group with same members does not resolve.
Outside of those two issues, UI is greatly improved and more streamlined.
For the second item, see the following in the log: [2020-10-04 11:57:12.6656] WARNING[29022][C-00000009]: res_musiconhold.c:934 _get_mohbyname: Music on Hold class 'None' not found in memory. Verify your configuration.
Hello, thank you for your feedback, about ring group, does it really work before. I think we have an issue about ring in the group. Check https://wazo-dev.atlassian.net/browse/WAZO-1980
Yes, it did “work” before and by work in this case I mean that the caller heard ringing while the ring group was also ringing. To the point of the link in your post above, it did in fact answer the call and start billing from the trunk even though it was still ringing to the originator - that had been the same behavior in Xivo going several years back, so I can add the workaround as a try (and that may even solve the moh issue).
On the configuration where the behavior changed, I have two ring groups that have overlapping members. The one ring group updated (and has the line for musicclass in) while the other one did not (and does not have that line in) - I am not sure exactly why, but the one without “musicclass = None” provides a ringing tone instead of music, which (along with the error message) leads me to believe that “None” is not handled, but blank is.
Tested the work-around on the link to use the noanswer and it works like a charm! Confirmed it does not answer and start billing the trunk while ringing, the originating caller hears the ring tone as opposed to moh and the call transfers as expected when answered.
Ok well so for the moment we are waiting to fix correctly this issue in a futur iteration. Thank you for your feedback.