Cloud PABX with PSTN Calling Network Considerations

We have an old Meridian phone system which is about the same size as a small car. As part of our wider strategy to move most of our core infrastructure to Azure, we have begun testing Microsofts “PSTN calling” add-on to the Skype for Business client. PSTN calling requires no on-premises infrastructure (ie SIP trunks or a session border controller) and can leverage either your internet circuit or express route links. The service has been available for some time in the US, although there is now a preview available in the UK for some select customers. For more information about the service itself, have a look here.

I have touched on our use of a squid proxy previously with regards to accessing Skype for business/O365. The need for this is necessitated mostly by my reluctance to write a firewall policy allowing end clients to access the huge range of (changing) subnets located in Azure directly. While our Cisco ASA’s do support DNS names, they do not support wildcard domains (how could they? they need to perform DNS resolution to resolve a name to an IP). Although MS best practice says “dont use a proxy, make exceptions”, I really don’t see a great way to write firewall policies to make this workable. The squid proxy provides a low latency method of accessing this vast list of URL’s for these services. We don’t do anything fancy on them – no SSL decryption, virus scanning, URL categorisation. A PAC file then defines which URL should go through Squid, and which should go through our main internet path (Zscaler FYI).

Traditionally we have protected voice traffic by marking packets with DSCP values and writing a QOS policy to protect this bandwidth. QOS really needs to be setup end to end, otherwise congestion somewhere can cause voice/video degradation. A QOS GPO will usually mark the Skype packets, as they are expected to be in a certain port range. The problem with a Squid server in the chain is that Skype will be accessed on the Squid listening port (3128) by default, not the Skype port ranges (49152:57500). You could write a GPO to mark anything going to the squid server, but what happens if non voice/video traffic goes there as well? This will be marked unintentionally. Text conversations, files, videos etc will all be tunnelled over port 3128 so we don’t be able to distinguish them by GPO.

What is the solution? I’m not so sure yet!

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.