Admin SIP and Audio (RTP) Settings

SIP Settings

Use Short SIP Headers: Some SIP headers have a short form (e.g., the From header gets shortened to f, the To header becomes t, and Via becomes v). Short headers have the advantage of saving space in the messages, reducing overall probability of running into problems with maximum message size in UDP. Although it is quite simple to support this, some devices do not support short headers. For this reason, the system offers both short and long. In order to maximize interoperability, keep the default value (long). If you are running into UDP packet fragmentation problems (message size above 1492 bytes), switch to the short header form.

Loopback detection: In multi-tenant environments it can happen that a call from one tenant ends up in another tenant, although the Call-ID is the same. This can cause problems with loops and stress the system. Because of this for single tenant deployments it is recommended to keep the detection on. In multi-tenant environments it may stay on if the call routing is done with a B2BUA router that picks a new Call-ID for the call into the other tenant.

SIP UDP Ports: If you are using SIP over UDP, you need to set this field. The default port for UDP is 5060. Multiple ports are permitted (e.g. 5060 5064) and it is also possible to bind the port to a specific IP address (e.g. 192.168.1.2:5060 [::]:5080). There is usually no need to choose a standard port, so that a random port can be used to avoid unneccessary exposure of the UDP port to the public.

Accept UDP packets only from enabled addresses When this setting is on, the PBX will accept UDP packets only from addresses that were automatically or manually enabled in the SBC, for example trunks or known client IP addresses. This helps significantly to reduce traffic from scanners (see below).

SIP TCP Ports: If you are using SIP over TCP, you need to set this field. The default port for TCP is 5060 however it is beneficial to choose a random port.

SIP TLS Ports: If you are using SIP over TLS (Transport Layer Security - Security over TCP), you need to set this field. The default port for TLS is 5061 however it is beneficial to choose a random port.

Proposed SIP transport protocol: When generating provisioing files for VoIP phones, the system has to make a decision what transport protocol to use. This can be done on system, tenant and extension level. This setting set the system level value. If there is no protocol selected, a VoIP phone default will be taken.

SIP IP replacement list: This setting applies to a system that is used in a DMZ zone with NAT (e.g., to connect remote phones to a system that is not on a public IP address). In this case, when the system builds the remote SIP packets, it will use the public IP address of the router. The setting should include a list of local IP addresses and their replacements. Whenever the system finds a local address in the list, it replaces the local address with the remote address, so the SIP messages from the system will look as if they were sent from the replaced IP address. The format of the list is LocalAddress/RemoteAddress [LAdr/RAdr]. Both the LAdr and the RAdr must be an IPv4 or IPv6 address (e.g., 192.168.1.2/203.4.5.1). DNS addresses are not resolved here.

(Note)

Most of the time, it is advisable to use the IP routing list (below) instead of the SIP IP Replacement List for better control and coverage.

IP routing list: The IP Routing List setting is used to override the operating system IP routing table and is linked to the routing table (this setting will be consulted by the system before consulting/using the operating system). Whenever the system wants to find out the IP address that is being used when sending a SIP packet, it steps through the list and looks for a match (using the netmask Mask ) to a destination address (DAdr). If there is a match, it uses the provided IP address (LAdr). The format of this field is DAdr/Mask/LAdr [DAdr/Mask/LAdr]... Both the DAdr and the LAdr must be an IPv4 or IPv6 address (e.g. 192.168.1.2), DNS addresses are not being resolved here. The mask must also be in the form of an IP address. The PBX (starting version 65.0.5) understands the pattern public as a shortcut for 0.0.0.0/0.0.0.0/public (see below) and private expands to patterns that match private destinations with the private IP addresses of the PBX.

• Example private public: This example tells the PBX to use its private IP addresses when communicating to other private IP addresses addresses and use the public IP address for everything else.

• Example 192.168.2.1/255.255.255.0/192.168.2.25 192.168.5.1/255.255.255.0/192.168.5.25 0.0.0.0/0.0.0.0/75.150.87.10 means to use 192.168.2.25 for 192.168.2.x addresses, use 192.168.5.25 for 192.168.5.x addresses, and use 75.150.87.10 for everything else.

• IPv6 addresses are possible as well. For example ::/::/12:34:56::1234 would always use the IPv6 address 12:34:56::1234.

URL for polling the public IP address: The PBX can poll an external server for its own IP address. This is useful in environemnts where the IP address changes periodically (for example, assigning new IP addresses by the service provider to better utilize the IPv4 address pool) or when another internet connection must be used because of a failover. The address will be available in the symbol "public" that can be used in the IP Routing List (see above), for example "0.0.0.0/0.0.0.0/public". The web server must return either the IP address in ASCII-format (e.g. 12.23.34.45) or in JSON format with an element called "ip" for example: {"ip":"12.23.34.45"}. You can use a service like "https://api.ipify.org/?format=json" but of course you can also just use your own service for that.

Interval for polling the public IP: This settings defined the frequency that the PBX should use to poll for the public IP address. Setting this value low will increase the speed for detecting an IP address change, but it will also increase the traffic.

Audio (RTP) Settings

The Real Time Protocol (RTP) ports are used for sending and receiving media. Be sure to specify a reasonable port range so that you have enough ports for all open calls. A port range of 100 ports is not unusual. Most user agents send RTP media data from the same port on which they expect to receive data. This is useful when a user agent sends media from behind NAT. The system can use this mechanism to establish a two-way media path, even if the user agent is not able to determine its public IP address for media and is behind NAT.

Port Range Start and Port Range End: This setting represents the RTP port range that the system will use for media sessions. The end must be higher than the start. Valid values are 1 to 65535, however in order to stay out of the range of standard ports it is suggested to pick ports higher than 2048. If you are using e.g. port 5060for SIP UDP, it is also useful to make sure that the RTP port range does not include that port. The range needs to be big enough to open four ports for each call, so for example for 100 calls 400 ports would be needed. Choosing a wider range helps avoiding overlapping media streams, e.g. because endpoints are not stopping sending media. The default for the range is 49152 to 65534.

Follow RTP: Some user agents use different ports for sending and receiving. Although they will not be able to operate behind NAT, they are within the scope of the IETF standards. With this setting, these devices can be made compatible. By default, this flag is set to On. If you have trouble with devices that use different ports for sending and receiving, try turning this flag off. Some troublesome devices also have a flag that can be used to turn the usage of different ports off. This behavior can be controlled on a trunk level, as well. If only a specific trunk has this problem, use this setting only on the trunk level.

Codec Preference: The Codec Preference setting allows you to select the codecs that will be supported on the system. The codecs that are allowed on the system are shown at the left. If you do not want to use a particular codec, click the codec, then click Remove. This will move the codec to the right-side selection box, removing it from use. The system comes with recommended high-quality codecs like G.711 µ-law (0), G.711 A-law (8), G.722 (9), G.726 (2), or GSM 6.10 FullRate (3). Codecs can be changed without restarting the service.

Lock codec during conversation: In certain cases, the system can switch to a common codec (advertised by both end devices) to avoid the transcoding during the call setup. Even though this is legal from the protocol’s point of view, many devices still cannot change codecs midstream. To avoid this problem, you must enable this feature. Once this is set, the system will not switch the codec during the call setup. This may introduce transcoding, which is a CPU-intensive job. Default is off.

Use SAVP in SDP: When negotiating SRTP, some devices are unable to parse SAVP in the SDP packets. In that case the setting needs to be turned off or those devices need to run a newer firmware.

Packet length (in ms): This is the ptime parameter in the session description protocol (SDP). The default is 20 ms. Longer packets slightly reduce the bandwidth, however at the cost of longer delay and lower perceived quality.

Always send packet size: Some devices are unable to deal with varying packet sizes. In that case the PBX needs to fix the packet size during the negotiation, however it is recommended to upgrade those devices to a newer firmware instead.

Multicast IP Addresses: By default, the operating system uses a more-or-less random interface to send multicast packets out from the system. Especially when the system has more than one IP address, it becomes random from which interface the PBX is sending out multicast packets. With this setting, you can tell the PBX from what IP addresses it should send multicast RTP packets into the network. For example, when you put 192.168.1.200 10.2.3.4 there, it will open two sockets and bind them to the provided IP address. Then when RTP multicast packets have to be sent out, it will send them from those sockets.

Multicast TTL: In some networks it is important to specify how many hops the multicase packets should take. For that the PBX has the setting "Multicast TTL".

Bind to specific IP address (IPv4): The system opens RTP ports on this IP address only. This is useful if you have a dual NIC machine and want to use only on one interface for RTP. If this is left blank, then the system will use all the interfaces it sees in the machine.

Bind to specific IP address (IPv6): IPv6 equivalent of the above field.

SIP/UDP

By default, the SIP protocol is using UDP as transport layer. This has several drawbacks, including UDP packet fragmentation and reassembly that typically lead to problems when the packet size exceeds the maximum size fo a UDP packet (typically 1492 bytes). The other major problem with UDP is that IP address spoofing makes denial of service attacks easy.

Most VoIP phones support TCP/TLS. The provisionin profiles for the supported devices take advantage of this. Typically there is no need to enable UDP except for SIP trunks.

In order to reduce the problem there are a few things that can be done. The first simple, but helpful step is to use a non-standard port for SIP/UDP. Most scanners scan only port 5060, and moving the SIP UDP port to another port significantly reduces the amount if scanning traffic that the PBX receives.

Another step is to accept UDP packets only from enabled addresses (see the flag above). This will open the SIP/UDP port, however accept traffic only from addresses that were enabled for UDP. The PBX does this automatically for SIP trunks; when using other devices like VoIP phones or IoT devices, the addresses for the devices must be added to the SBC. Other packets are just being ignored, and a scanner will not be able to identify the port as SIP/UDP port.

This setting goes in tandem with the setting to ignore packets that do not match a tenant DNS name on the system (in the security settings). When both of these settings are turned on, the PBX will accept random UDP packets only if they are coming from listed IP addresses that match a tenant name. This significantly reduces the risk of exposing information to a scanner.

When it is not possible to exclude SIP/UDP traffic e.g. because there are too many clients that need to use the UDP transport layer, the SBC rules for automatically blocking addresses apply. This typically gives scanners only a few attempts per hour to try passwords, making it expensive to find a backdoor into the system.

It is still possible to flood UDP packets on the PBX port. However when the above mechanisms are enabled, the PBX will quickly discard UDP packets without the need to run them through the SIP stack. This is comparable with the effort to process a TCP SYN message. The CPU graph for the main thread will show how many UDP packets can be handled without overloading a specific system setup, e.g. by using SIP tool like SIPSAK to flood packets on the PBX.