Vodia PBX Posted December 12, 2023 Report Share Posted December 12, 2023 We have made a 68.0.34 build with a couple of fixes that can be seen in the release notes. Nothing really spectacular, but a few annoyances that came up in the past few weeks. One of the major points is an improved Teams behavior, especially if you are using IPv6 for Teams please make sure that the associated addresses are up to date with the SIP trunk template. Quote Link to comment Share on other sites More sharing options...
RichardDCG Posted December 12, 2023 Report Share Posted December 12, 2023 ... still nothing for managing call recordings? https://forum.vodia.com/topic/19272-manage-call-recordings/ Quote Link to comment Share on other sites More sharing options...
Scott1234 Posted December 13, 2023 Report Share Posted December 13, 2023 Thanks, the zoho fix will be apricated by my zoho customers that log in and out of agent groups a lot. Does this teams related fix's fix being able to use teams call park? Label for night more active/inactive was wrong - Does this mean the service flag naming difference between auto attendant and call queue? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 13, 2023 Author Report Share Posted December 13, 2023 22 hours ago, Scott1234 said: Does this teams related fix's fix being able to use teams call park? Hmm actually not sure. There were some changes with the identification with the trunk, and that could have to do with Teams. I guess we'll find out! But I know that the net mask was causing a lot of erratic problems with Teams trunks that were set up versions ago when the associated IP addresses were a much smaller range. 22 hours ago, Scott1234 said: Label for night more active/inactive was wrong - Does this mean the service flag naming difference between auto attendant and call queue? It was really just the label. The settings internally were not affected so that you don't have to change anything, it will just show on the front end the other way around and hopefully now makes sense. Quote Link to comment Share on other sites More sharing options...
Scott1234 Posted December 14, 2023 Report Share Posted December 14, 2023 11 hours ago, Vodia PBX said: Hmm actually not sure. There were some changes with the identification with the trunk, and that could have to do with Teams. I guess we'll find out! But I know that the net mask was causing a lot of erratic problems with Teams trunks that were set up versions ago when the associated IP addresses were a much smaller range. It was really just the label. The settings internally were not affected so that you don't have to change anything, it will just show on the front end the other way around and hopefully now makes sense. Great, Can you give a bit more insight on these, just curious to its creation to better understand the use case and or effects Added global setting provserv2 for Yealink Find the right trunk with trunk domain match and IP thanks Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 14, 2023 Author Report Share Posted December 14, 2023 8 hours ago, Scott1234 said: Added global setting provserv2 for Yealink Yealink now runs the cloud provisioning server in different regions (e.g. GPDR so that the data is physically stored in the EU). In preparation for that, the PBX needs a new setting for the server URL. 8 hours ago, Scott1234 said: Find the right trunk with trunk domain match and IP There was a problem that the PBX would not find the right trunk when there are multiple trunks associated with the same IP. Quote Link to comment Share on other sites More sharing options...
Scott1234 Posted December 15, 2023 Report Share Posted December 15, 2023 Thanks, ok so that sounded ok for an upgrade without danger. Now my YMCS looks like this, basically all offline expect the pbx that was not upgraded. I did sync and reboot handsets to see if any diff but same same. Quote Link to comment Share on other sites More sharing options...
Scott1234 Posted December 15, 2023 Report Share Posted December 15, 2023 Switching back the updated cfg line, makes them come back online. dm.server.address = {get provserv2} back to, dm.server.address = dmtcp.yealink.com Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 26, 2023 Author Report Share Posted December 26, 2023 On 12/15/2023 at 8:09 AM, Scott1234 said: dm.server.address = dmtcp.yealink.com Hmm we preset provserv2 to us-device-scheduler.ymcs.yealink.com. I hope that that address does not blacklist requests from other regions? Seems like dmtcp.yealink.com is a better choice for now. Quote Link to comment Share on other sites More sharing options...
jvoiptel Posted January 11 Report Share Posted January 11 On 12/15/2023 at 8:09 AM, Scott1234 said: switching back the updated cfg line, makes them come back online Did you ever get this to work with dm.server.address = us-device-scheduler.ymcs.yealink.com ? I understand Yealink is going to ultimately migrate all customers to this new endpoint. Quote Link to comment Share on other sites More sharing options...
Scott1234 Posted February 16 Report Share Posted February 16 I notice when you release versions such as 68.0.36 I installed one that was build date 31st then I see there is now a build date 5th feb, can this not be documented and made public, I would like to know what changes within these build dates, so I can be aware of any anomalies and changes, or if you add items to the release notes, segment with build date markers ? Quote Link to comment Share on other sites More sharing options...
RichardDCG Posted February 16 Report Share Posted February 16 1 hour ago, Scott1234 said: I notice when you release versions such as 68.0.36 I installed one that was build date 31st then I see there is now a build date 5th feb, can this not be documented and made public, I would like to know what changes within these build dates, so I can be aware of any anomalies and changes, or if you add items to the release notes, segment with build date markers ? This has happened before as well. I was under the assumption that the even builds were production and odd were beta. Production builds should not change within the same build stamp. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.