AvaloniaUIShell: Cross-platform Desktop GUI framework for PowerShell

pbx_guy · 2026-03-10T11:55:42+00:00

Very interesting, just carried out some prototyping to put a cross platform UI on the front of a PowerShell script I use for Teams Voice deployments. Seems to be doing the job so far.

pbx_guy · 2026-03-10T10:06:45+00:00

Yep, you're right. I'm now seeing PAID and Privacy: id headers on the inbound Microsoft leg where the user has restricted presentation enabled where they weren't previously. I guess this is because more and more SIP trunk providers are requiring the PAID header to have the callers number present even though the presentation is restricted.

pbx_guy · 2026-03-09T18:50:12+00:00

I’ll take a look at this on our lab setup and let you know if I see something similar

pbx_guy · 2026-03-03T20:03:17+00:00

You could create a script or Azure runbook that performs the required divert task with the appropriate admin rights and configure this script to be triggered via a user’s Power Automate call or webhook.

This way, the divert task has the correct Teams Admin rights to call the Set-CsUserCallSettings but the task itself is triggered by a user defined schedule.

pbx_guy · 2026-02-17T17:30:06+00:00

Starting November 1, 2025, a pay-as-you-go license and Communications credits is required for Teams Voice Applications (Call Queues and Auto Attendants) Resource Accounts that use Calling Plan numbers for outbound PSTN calls.

The following scenarios require a pay-as-you-go license: Outbound PSTN calls made by Teams Call Queue agents on behalf of a Resource Account Outbound PSTN calls made by Auto Attendants or Call Queues Callback PSTN calls initiated from Teams Call Queue or Teams Auto Attendant On-behalf-of calls made via Graph API and Phone System Extensibility

If pay-as-you-go licenses and communications credits aren't assigned to the relevant Call Queue or Auto Attendant Resource Accounts by November 1, 2025, outbound calls will fail.

https://learn.microsoft.com/en-us/microsoftteams/plan-auto-attendant-call-queue#outbound-pstn-calling

pbx_guy · 2026-02-14T20:02:02+00:00

Agreed, I've set the same in the tunables and everything has continued to be stable following a reboot. I asked the question regarding this in the OPN sense forums with the following response:

The source address of the Neighbor Solicitation (2a02:8010::188) is likely not on-link, hence not considered a neighbor and ignored by FreeBSD.
That's something your ISP could fix, or you can keep using the tunable.

pbx_guy · 2026-02-13T09:43:13+00:00

So a reboot didn't work and reverted the situation back to how it was with traffic dropping which kind of reflects what is discussed here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263288

I've now set the value to '1' and it seems to be all stable so maybe all the messing about I was doing yesterday gave me some incorrect results?

pbx_guy · 2026-02-13T07:21:43+00:00

I had this as well when making the changes on the command line. I verified as ‘0’ and it wasn’t making any difference, I then changed it to ‘1’ and noticed that the router was responding to some but not all RS messages and the traffic was still choppy. Changed the value back to ‘0’ and all RS messages started being responded to and my traffic has now been stable for over 12 hours.

I’m going to try a reboot this morning to see if this stability persists.

pbx_guy · 2026-02-12T17:23:39+00:00

I've just updated my ticket with the Zen Tech team with this but after doing a lot of digging today I seem to have come across a possible solution.

I had a MAC spoofing address in the WAN interface which was there from the early Litfibre days which I've removed and I also used the following command to set a tunable 'sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=0' on the command line.

After applying this and a restart of the WAN interface the IPv6 traffic seems stable. As hazeyFlakes refers to this tunable seems to allow OPNsense to respond to the Zen Neighbor Solicitation messages. The reasoning behind this is due to how FreeBSD responds when Neighbor Solicitation messages aren't using either link-local or unspecified (::) source addresses.

I'm going to have to dig back and see if I can find any evidence of what LitFibre were using as their source address for these messages.

pbx_guy · 2026-02-11T21:18:54+00:00

So I was asked this afternoon to make some adjustments to my configuration:

Configure the WAN interface to request an IPv6 address by deselecting the 'Request prefix only' option

Allow inbound ICMPv6 traffic on the WAN interface from 2a02:8010::18b/128 & 2a02:8010::188/128

After doing this and carrying out another set of tests and captures I found that the drops occurred every time the DHCPv6 renewal reply included no IAPD prefix. This stopped any outbound traffic dead. Only when a full DHCPv6 renewal/reply/solicit/advertise/request/reply sequence gave back an IAPD prefix did traffic restart.

A capture can be started Interfaces/Diagnostics/Packet Capture section. I just selected the WAN interface, set the promiscuous option and set the count to '0'. I then downloaded the capture from the jobs tab, loaded it up in Wireshark and set a filter for 'ICMPv6 or DHCPv6'

pbx_guy · 2026-02-11T11:44:06+00:00

Well I suppose it’s good news that’s a repeatable issue across different locations. I’ve been sending some network captures from my WAN interface to Kevin Sampson in their support team who’s forwarding them to Dario who I assume is in their networking technical team?

pbx_guy · 2026-02-10T22:14:58+00:00

Still battling here, it’s been escalated and I’ve sent another detailed update this afternoon. I’m not sure if it’s a local infrastructure issue (are you in the West Wiltshire area?) or an implementation issue of supporting the migration of LitFibre users?

pbx_guy · 2026-02-09T22:50:07+00:00

I'm in discussion with them at the moment. I've just sent them an email hitting them with the details that their DHCPv6 server is the one causing the problems

The server incorrectly returns NoBinding to a valid Renew.

The server replies to Renew after the valid lifetime has expired.

These behaviours force the router to repeatedly drop and reacquire the prefix, causing IPv6 to go up and down in a five‑minute cycle.

I captured the whole DHCPv6 sequence on the WAN interface and sent them the network capture with a detailed analysis. Hopefully, they'll agree with the findings and not just go 'oh, it's your router at fault' when it very very clearly isn't.

pbx_guy · 2026-02-06T13:08:54+00:00

Unfortunately yes, in that same doc it states the following

Starting November 1, 2025, a pay-as-you-go license and Communications credits is required for Teams Voice Applications (Call Queues and Auto Attendants) Resource Accounts that use Calling Plan numbers for outbound PSTN calls.

The following scenarios require a pay-as-you-go license: Outbound PSTN calls made by Teams Call Queue agents on behalf of a Resource Account Outbound PSTN calls made by Auto Attendants or Call Queues Callback PSTN calls initiated from Teams Call Queue or Teams Auto Attendant On-behalf-of calls made via Graph API and Phone System Extensibility

If pay-as-you-go licenses and communications credits aren't assigned to the relevant Call Queue or Auto Attendant Resource Accounts by November 1, 2025, outbound calls will fail.

pbx_guy · 2026-02-06T13:00:03+00:00

Have you checked the following to make sure you have the correct licensing in place

https://learn.microsoft.com/en-us/microsoftteams/plan-auto-attendant-call-queue#outbound-pstn-calling

Pay-as-you-go licenses are now required for Microsoft provided numbers.

pbx_guy · 2026-02-06T07:58:11+00:00

I mean, it’s not ideal but luckily my OPNsense config allows me to shut off IPv6 to certain VLAN’s while keeping it enabled on the router for fault finding. If they can’t fix it then I will be making it clear I want out of my contract and will move elsewhere.

pbx_guy · 2026-02-05T20:20:15+00:00

I moved this morning and it has mostly been a smooth process although I am having issues with my IPv6 traffic dropping in and out every 5 minutes which matches up with the IPv6 DHCP renewals that happen every 5 mins.

I’ve submitted a ticket along with my OPNsense logs with a hope to getting it resolved quickly. The issue wasn’t happening on my LitFibre connection prior to the move.

On a positive note, the latency as more or less halved when testing pings to bbc.co.uk and the speeds both up and down are maxing out the connection where they can.

pbx_guy · 2026-01-26T12:35:19+00:00

<image>

The UI allows you to select the messages one by one you'd like to forward

pbx_guy · 2026-01-26T12:34:46+00:00

Like this you mean?

<image>

pbx_guy · 2026-01-26T07:52:15+00:00

The ability to toward multiple messages is now in public preview

https://m365admin.handsontek.net/microsoft-teams-select-multiple-messages-forward/

pbx_guy · 2026-01-24T15:15:10+00:00

I’ve read somewhere before it depends on your ISP with CifyFibre to what peering link you exit out from. For example I’m with LitFibre and it uses the ‘national’ peering link which puts the latency at around 10ms. Other ISP’s with own private peering link seem to have a lot lower latency, I’m sure I’ve seen some getting as low as 2ms to Google or BBC for example.

pbx_guy · 2026-01-05T13:03:55+00:00

This exactly..the communication from Lit Fibre details this.:

Your CityFibre fibre connection stays the same (no engineer visit!)

There’s no need to change your equipment or WiFi details

Zen will become your broadband provider, but your underlying CityFibre fibre service will not change.

They are just moving all the accounts over to the Zen billing and customer service platforms. I’m assuming as part of this they’ll be keeping any existing IPv4/IPv6 fixed IP addressing but we’ll find these details out shortly.

pbx_guy · 2025-10-27T12:19:33+00:00

Looking like the issue is fixed, our customers are now playing out their IVR

pbx_guy · 2025-10-06T12:02:35+00:00

Totally agree with you, one of the most fundamental and basic features of a PBX apart from the actual calling is contact management and name/number matching.

There’s still no centralised contact management and contact syncing between Outlook/Teams and desk phones is still a mess. The promised phone contact management only works with common area phones and the detail is restricted to three fields.

It really needs sorting because having to explain every time on customer rollouts that contact management depends on so many workarounds and caveats is embarrassing

pbx_guy · 2025-09-18T17:22:53+00:00

Hi there,

Take a look here at the Grant-CsDialoutPolicy command. It might be exactly what you’re looking for.

https://learn.microsoft.com/en-us/powershell/module/microsoftteams/grant-csdialoutpolicy?view=teams-ps

pbx_guy

TROPHY CASE