Trunk Settings

General Settings

  • Name: This setting allows you to name the trunk (the name and type of trunk can be changed at any time).
  • Type: Three types of trunks are available.
  • Direction: Traffic can be limited to either inbound traffic or outbound traffic.
    • Inbound and outbound: Typical setting.
    • Inbound only: Limiting traffic to inbound traffic prevents users from using the trunk for unauthorized calls.
    • Outbound only: Enable this setting if you are using a trunk for outbound traffic only. It makes it easier for the system, as the trunk will not try to match inbound traffic to this trunk.
  • Global: This setting is used only in multi-domain environments. When it is enabled, calls that come in on this trunk are permitted to jump into other domains if a match is found on a global alias name. (If the direction is not only inbound, then other domains may use this trunk in their dial plans for outbound calls.) When this setting is disabled, the system does not search for tel:-alias names.
  • State: This setting enables you to temporarily disable a trunk rather than delete it from the system altogether. When a trunk is disabled, it cannot be used for routing, registration, etc.
  • Is Secure: This setting is used to indicate that outbound calls on the trunk can be treated as secure calls. For example, when the trunk goes to a local PSTN gateway, you might decide to treat this call as a secure call. Incoming calls with the SIPS scheme will ask the Vodia PBX system to ensure that the call be kept secure end-to-end.


  • Display Name: The display name is used for display purposes in the trunk listings page. This setting is the friendly name of the SIP From field and can be changed at any time
  • Account: The account is typically the main DID on the trunk.
  • Domain: The domain is typically the upstream registration server or SIP server. It can be an IP address or a domain name.
    Example: (if the service provider is using DNS SRV records, it could be
  • Username: The user name and password are used for authentication purposes (not all registrars require a different username for authentication).
  • Password: The password needs to match the password from the trunk provider.
  • Password (repeat): Confirmation of the password.
  • Proxy Address: This setting defines where requests that are made of this trunk will be sent. When this field is set, requests will be sent to the specified address. Otherwise, the dial plan replacement field will be used to route the request.
    The outbound proxy field follows the definitions of RFC 3263 (“Locating SIP Servers”). You may use the fully qualified domain name (FQDN) for a SIP server. If you add a colon with the port number after the FQDN DNS, a resolution will be used; otherwise, the system will try DNS NAPTR and DNS SRV first. You can force the SIP connection to use TCP by supplying an outbound proxy.
    Example: sip:hostname:5060;transport=tcp
    Important: The outbound proxy is an important setting. If an outbound proxy is not used, then the system will assume that SIP requests on this trunk can come from any location. This will make it difficult for the system to match incoming SIP requests. Unless you want to receive requests from any location on the Internet, you should specify an outbound proxy.
  • Explicitly list addresses for inbound traffic: This setting allows you to explicitly state trusted inbound proxy addresses and enables you to identify the origin of the request. It is ideal for VPN environments or when routing calls between offices, as it allows you to create a single trunk and specify the IP addresses of the other locations. The addresses can be either IP addresses (with an optional port number behind) or a DNS A or AAAA address.

Routing and Redirection

  • Failover Behavior: When the trunk receives an error code, it might send the call back to the dial plan and continue the matching process. The system continues the dial plan with the next highest priority, ignoring entries with lower or same priority. This is useful when the trunk is just a “trial” to place the call. One example is when several PSTN gateways are available for terminating the call and one gateway does not accept any more calls. Another example is when you first try to route the call via a peer-to-peer call using ENUM or other location methods and only if such resolution does not result in a connection fallback to a PSTN call. The setting allows four behaviors:
    • No failover: This is the default behavior. In this case, the caller will receive the error code as a result of the attempted call.
    • On 5xx and 408 error codes: This will trigger failover only when a 5xx or 408 class error code is received. PSTN gateways typically return 5xx class error codes when all channels are in use; however, this mode will allow you to switch to the next PSTN gateway when a line is busy and will not trigger the failover.
    • On all error codes: In this case, all error codes will trigger the failover process. Note that call redirect will also be treated as an error code, as the redirection destination can easily be abused to route calls through expensive routes.
    • Always, except for busy response: Except if the remote party is busy, the system will try alternate routes.y/li>

    If you are using failover, you have the option to specify a request timeout value for the trunk. By default, this is 32 seconds (the SIP default request timeout). However, in many cases, it makes sense to specify a shorter value. After the request timeout, the system will internally generate a “408 Request Timeout” response code and process it according to the failover rules.

  • Accept Redirect: Use this setting if your trunk should respect redirect codes. By default, this introduces significant security risks because the system cannot determine whether these redirects introduce additional costs (redirection to expensive numbers). Therefore, enable this setting only if you are sure that your service provider or SIP gateway does not abuse this feature. This flag is especially important when you use the system with Microsoft Exchange or other Microsoft products, such as the speech server. Also enable this setting when you have a trunk that comes from another system. This will make it possible to call from one system to another.
  • Assume that call comes from user: This setting is used for trunks that accept redirects. The settings must be an extension in the domain of the trunk. This setting is necessary in order to determine what dial plan to use, and it is also necessary to charge a user on the system for the call. For regular trunks, you should leave this field empty.
  • Destination for incoming calls:: This setting sets the destination where the calls from this trunk should go, e.g. an Auto Attendant.

Number/Call Identification

  • Prefix: This setting is used as a representation of the system when making outbound calls. If an ANI has not been set, the system puts the prefix (if there is one) in front of the primary account number and uses that as the ANI before it leaves the trunk. This is very useful in cases when a trunk deals with a range of numbers (typically outside of the NANPA area, e.g., Europe). The "extension" number is put after the prefix.
  • Trunk ANI: You can configure each trunk with an ANI (Automatic Number Identification). ANI is a service that tells the recipient of a telephone call the telephone number of the person making the call. In most cases, the ANI is used in the From field in the SIP packets or the caller ID.
  • SIP Caller-ID Presentation: This setting tells the system how to present the caller-ID on the trunk. The following values are available for configuring this setting:
    • RFC3325 (P-Asserted-Identity): RFC 3325 describes a way to represent these two numbers. In most cases, it makes sense to use the P-Asserted-Identity header. In this case, the From header in the INVITE represents the display number, while the P-Asserted-Identity header has the network number. A similar representation can be done with the P-Preferred-Identity header. The system changes only the name of the header from P-Asserted-Identity to P-Preferred-Identity. The rest remains the same, as in the first method.
    • No Indication: No Indication: This method simply discards the display number and uses only the network number in the From header. This method is a fallback when the provider cannot handle any other method. The disadvantage here is clearly that any redirection information gets lost.
    • Remote-Party-ID: Remote-Party-ID: This method is described in a draft that expired years ago; however, there is still a lot of equipment outside that is supporting this method. In this case, the From header in the INVITE represents the network number, while the P-Asserted-Identity header is the display number.
    • RFC3325, but don't hide: RFC 3325, but don’t hide: This method should not be used. It has been used in environments where the fields have gotten mixed up, and it is creating even more confusion.
    • Custom Headers: Custom headers are discussed in detail on the Custom Trunk Headers page.
  • Rewrite global numbers: When you are using a trunk, you may have to represent the telephone number in a specific format. For example, in the NANPA area, you might want to use 10 or 11 digits to represent a national number. When Use + symbol at the beginning is selected, the system will automatically use 11 digits.
  • P-Charging Vector: The "ICID" (IMS Charging Identifier) setting is used in the IMS(IP Multimedia Subsystem) environment. The setting is sent in the P-Charging-Vector header of the SIP packets on this trunk and it is essentially a token that identifies the trunk. If your provider uses this header, you should put it into this field.
  • Generate unique extension identifier: This setting allows you to use the extension’s EPID instead of the ANI if the extension’s EPID has already been set. If extension’s EPID is not set, “generate” a new EPID and use it (and set it for extension for the future use too).
  • Interpret SIP URI always as telephone number: When a call comes into the system, the system needs to know how to interpret the number. In SIP, the URI contains a domain name; however, in most cases, the domain name should be ignored when interpreting the URI coming from this trunk (because the user portion is just a telephone number). Usually, this is indicated by the parameter “user=phone,” but not all service providers set this flag. By turning on the “Interpret SIP URI always as telephone number,” you make the system believe that this flag was set on the trunk call.
  • Caller ID update on trunk: This setting is used to update the caller ID information on the trunk. For example, if you want to update the caller ID that is sent to a remote party, when a call is transferred, you can use this setting. This is dependent on whether the trunk provider supports that feature.


  • Override codec preference: Use this setting to specify particular codec preferences for the trunk. By default, the system uses the codec preference of the system, which has the advantage of allowing the system to negotiate codecs in such a way that transcoding can be avoided. (When default mode is used, no codecs will be displayed on the left side of the codec selection box.) If it is necessary to enforce specific codecs on a trunk, choose a codec from the list of available codecs and click the button. Repeat as needed. Be sure to position the codec with the highest preference first. To delete a codec, click the Remove button. To move a codec up or down in the preference list, use the Up and Down buttons.
  • Lock codec during conversation: Locking the codec prevents someone from switching codecs in mid-conversation and ensures that the user agent continues to send and receive media properly. (Some user agents are not capable of changing the media once the conversation begins. ) When this setting is used, the Vodia PBX transcodes the stream so that changes made to the codec by the other side go unnoticed by the user agent.
  • Strict RTP Routing: This setting is needed because the IETF allows “RTP traffic send ports” to be different from “RTP receiving ports,” creating an extremely NAT-unfriendly situation. While most implementations today use the same port number for sending and receiving RTP, some gateways still insist on strict IETF compatibility. In such cases, this setting should be enabled. We recommend you keep this flag disabled (“No”) unless asymmetrical ports are required.
  • Trunk requires out-of-band DTMF tones: When this setting is enabled, the trunk will use RFC 2833.
  • Requires busy tone detection: When an analog PSTN gateway (e.g., FXO) is used, hangup detection can be an issue. In FXO, the hangup signal might be just a tone that needs to be detected. Unfortunately, no international standard exists for the disconnect tone. Incoming international calls might give you a disconnect tone that the system has to recognize. Of course, if the PSTN gateway is capable of detecting this, the task should be left to the PSTN gateway. However, as a fallback, you may also configure the system to perform the hangup detection. The disadvantage of doing this is that it costs additional CPU resources, and it might randomly disconnect calls; for example, if the other party plays back a tone that sounds like a busy tone, the call may be disconnected. The best way to avoid these kinds of problems is to use a digital line, e.g., a SIP trunk.
  • Ringback: This feature was introduced to deal with network operators who were unable to deal with early media. Although using the 180 Message simplifies the signaling in forking calls scenarios, it creates additional delay when the called party picks the handset up and the first samples on the conversion may not be transported. We strongly recommend leaving the flag set to Media (which is default) and asking the operator to fix the problems with early media.
  • Force local ringback: This setting is used in cases where the service provider sends back a 183 with SDP, but doesn't provide the ringback tone. With this setting, the PBX can force a local ringback.