68.0.34

[Vodia PBX]

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. 

[RichardDCG]

... still nothing for managing call recordings?  https://forum.vodia.com/topic/19272-manage-call-recordings/ 

[Scott1234]

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?

[Vodia PBX]

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.

[Scott1234]

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 

[Vodia PBX]

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. 

[Scott1234]

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. 

[Scott1234]

Switching back the updated cfg line, makes them come back online.

dm.server.address = {get provserv2} 

back to,

dm.server.address = dmtcp.yealink.com  

[Vodia PBX]

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.

[jvoiptel]

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. 

[Scott1234]

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 ?

[RichardDCG]

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.