Advanced SIP Settings

Changing values on this page requires in-depth knowledge!

Press Get default values to restore all settings on this page to factory defaults.

The Internet Gate is pre-configured to be SIP-transparent, allowing SIP traffic to effortlessly pass through the firewall. You do not need to tweak or configure the settings if all you want is getting simple SIP traffic through the firewall. Below settings are for additional functionality besides basic transparency.

Turn off ICE, STUN, uPnP and other “tricks” that your SIP client's try to use to get through ordinary firewalls. As the Internet Gate is SIP transparent such “tricks” are harmful and unnecessary - and might even actually stop SIP traffic from getting through the firewall!

The Internet Gate can enable SIP connectivity for remote users that use NAT devices without SIP support. It can adapt to characteristics of remote NAT devices.

FENT sends keep-alive packets to remote SIP clients behind non-SIP-capable firewalls to keep the SIP communications channel free to them.

Read more about FENT.

Define rules for limiting what SIP users are allowed to do. When a SIP message is received, this table is scanned top to bottom and the first row defining a rule that matches the method, URI and direction of the SIP message is used.

TLS (Transport Layer Security) encrypts SIP messages.

TLS is configured automatically on every network interface if any certificates has been installed in the unit. The default configuration uses the first server certificate installed in the unit and all trusted certificates. Interop is enabled and MTLS is not.
Only if you want to override the default configuration you need to use the table on the SIP Advanced page.

You can configure different TLS settings for each interface, specifying what certificates to use and trust, what methods the TLS server shall use, and what methods clients are allowed to use.

MTLS (Mutual TLS) requires all connecting clients to present a certificate that can be verified using trusted certificates.

Interop - OpenSSL has some workarounds for common bugs in popular SSL implementations called SSL_CTX_set_options(3). By enabling Interop you activate those workarounds, allowing connection to SIP TLS clients who have buggy TLS implementations.

Read more about TLS.

Read more about certificates.

Advanced settings for how Internet Gate forwards SIP messages. See Internet Gate's built-in pop-up help for detailed information about the settings.

The maximum number of active sessions (“simultaneous calls”) Internet Gate is allowed to handle is limited by license. To allow more, you need to purchase additional licenses.

Enter domains that should not be looked up using DNS. Use 127.0.0.1 as “Forward to” to specify a domain that should be handled by the Internet Gate. If a domain in DNS points at Internet Gate's IP address, but you want to use another SIP server you can enter it's IP address here. SIP messages addressed to that domain will then be forwarded to that IP address.

For example if SIP domain mycalls.com is handled by a SIP server on your LAN you can enter mycalls.com as Domain and the SIP server's LAN IP address as Forward to.

You can specify codecs (media coding format) you allow for SIP calls. When Internet Gate is used in B2BUA mode (with operator accounts or call transfer settings below) call transfers may not work unless only a single codec is allowed for all voice communcation. Recommended codecs for these cases are “pcmu” or “pcma”, which are the most common codecs supported by SIP phones.

Rules that limit access to the SIP server by matching the source IP address of the SIP message. With these rules you can black list users (or white list) based on source IP address. The list is scanned from top to bottom and the first match found is selected.

Miscellaneous advanced settings affecting Internet Gate SIP proxy and server behavior. See Internet Gate's built-in pop-up help for detailed information about the settings.

Support for RFC 3325 P-Asserted-Identity header.

SIP requests arriving from a trusted network will be regarded as properly authenticated if they contain P-Asserted-Identity header. P-Asserted-Identity will also be added to requests successfully authenticated by Internet Gate. 127.0.0.1 (internal address) is always regarded a trusted “network”.