Outbound Proxy
The information on this page is based on versions after 5.4.2 (May 27, 2016).
Available Transport Layers
The PBX can automatically generate the configuration files for a range of VoIP phones. Those configuration files also tell the phones to which address they should register, and what protocol to use. The PBX supports UDP, TCP and TLS transport layers:
Protocol | Description |
UDP | The UDP prococol must be support by all devices that claim to be SIP compliant. This transport protocol serves as the least common denominator. However for registering VoIP phones it causes a lot of problems because of a problems called "UDP fragmentation", when packets get too big to fit into a single UDP packet. Especially when a lot of codecs are presented by the phone, this limit can easily be reached. In that case it screws up the communication. There are many problems with UDP when the VoIP phone is behind a router or firewall, as there are several ways those devices behave in practice (symmetrical NAT) and how long those ports are kept open. Because of this unpredictable and erratic behavior, it is strongly recommended not to use UDP and use a connection oriented transport. |
TCP | The TCP makes sure that packets don't get lost between the client and the server. Many mainstream protocols such as HTTP and Email are using TCP for sending their packets back and forth, which make TCP an extremly robust and well-understood protocol in the Internet. The main drawback of TCP is that it is not encrypted. Some firewalls that are monitoring the traffic tend to change TCP packets, which can cause problems with the PBX. Today, most VoIP phones properly the TCP protocol for SIP, although it is not strictly mandatory according to the SIP protocol. |
TLS | TLS is based on TCP, but uses encryption. This makes it possible to negotiate secure keys for the voice packets as well, so that the whole call can be encrypted. The main problem with TLS is that the PBX should have a signed certificate. Those certificate can cost a significant amount of money and usually need to be renewed annually. |
By default, the PBX tries to provision TLS protocol, or at least the TCP protocol if the device supports it. Generally, this is the best chance for a seamless user experience.
Unfortunately, it is not always possible to use TLS or even TCP. Some firewalls block TLS traffic because they are not able to analyse the traffic, and some other firewalls might not be able to handle too many persistent TCP connections so that UDP might become neccessary.
PBX Address
When a phone wants to send a registration to the PBX server it needs to have a resolvable address for the PBX. The SIP standard provides several ways to discover the PBX address. By default, the PBX uses the IP address method which works well in environments where there is no DNS available.
Protocol | Description |
IP-Address | By default, the PBX determines what IP address the PBX needs to present to the VoIP phone. The way to figure out what IP address to present can be tricky; however the PBX has a reasonable way to determine this address which works well, even if the PBX is operating in a mixed IPv4/IPv6 address environment with multiple IP addresses. |
DNS-Address | Especially for hosted PBX setup where the provider is able to provide a DNS address for each domain, it makes sense to provision the domain name instead of an IP address. This makes it possible to use DNS SRV and NAPTR, especially for automatic failover from the client this is an easy way to provide multiple addresses where the phone can register. This method needs to be enabled by the setting "Use domain name instead of IP address" (Plug and Play Settings). |
Domain Outbound Proxy Pattern
The Domain Settings may contain a special pattern that tells the PBX what address to provision for certain addresses.
Along with the address, the PBX will also try to select the right port. This also depends on the transport layer, e.g. typically TLS has a different port than TCP or UDP.
Using the Outbound proxy pattern, the outbound proxy that is provisioned into the phones can be controlled based on their public IP addresses. A typical scenario is that an office which is using a hosted PBX uses a SIP-aware firewall that needs to receive the outbound traffic from all IP phones in that office. The value in this field is a list of patterns that looks like this: src/mask/adr[:port[/transport]]. If the phone to be provisioned matches the source address src with the netmask mask, it will use the outbound proxy made of the adr:port and transport parameters. The port and the transport are optional. If not present, they will be replaced with 5060 and udp.
So let's say that a tenant has two offices which have a VoIP router. The first office is at 1.2.3.4, and all traffic needs to be sent to 10.0.0.2. Then the first pattern would be 1.2.3.4/32/10.0.0.2. The second office would be in the VPN of the company and uses IP addresses 10.43.0.x, and the internal gateway is at edge43.company.com, using TLS on port 5061. Then the second pattern would be 10.43.0.0/24/edge43.company.com:5061/tls. In the domain setting the administrator would have to enter 1.2.3.4/32/10.0.0.2 10.43.0.0/24/edge43.company.com:5061/tls.
Selecting the Transport Layer
The transport layer can be pre-selected on extension level, on domain level and on system level. The setting is called "Proposed SIP transport protocol". Depending on the support of the VoIP phone and the provisioning template, the PBX will then try to provision the selected transport layer. If there is nothing set on the extension level, the PBX will try to use the domain level, and if that is also set to use the default value, it will use the system value, and if that is also on default it will attempt to use TLS, then TCP and as a last resort, UDP.
If the Outbound proxy pattern was set on domain level it will override the transport layer selected on extension, domain or system layer.
Changing the transport layer will take effect on the next provisioning event for the phones.