Trunk Settings
From Bizfon Wiki
Contents |
Purpose
Trunks are used to send and receive calls to devices that are not registered with the PBX. When a call is received by the PBX it checks to see if it is another extension and if not the dial plan is consulted to determine which Trunk to route the call to. The name Trunk comes from the premise that there is a physical connection between the PBX and an external device, like it used to be with traditional TDM based PBX's. For outbound calls extensions are linked to dialplans which select a trunk depending upon the number dialed. Inbound calls are received by the trunk and routed to the appropriate extension or account.
There are three types of trunks on the system:
- Registrations. The PBX registers to a remote system and itself looks like an extension to the upsteam system. This model is typically used when you have an account with an Internet Service Provider and you use this account for terminating your traffic. In this model, the PBX uses the number of the registration as caller-ID, regardless what extension is actually using the trunk. You can use this mode if the service provider supports SIP soft- or hard phones. This type of trunk can also be used if you want to connect two Bizfon systems together in a branch/head office configuration. The branch office can create a trunk and register to an extension on the head office pbx which can be called by any extension and routed to the branch office accordingly.
- Gateway. The gateway model does not register; it just sends the traffic to the destination. In this model, the PBX uses the caller-ID of the PBX to indicate the extension that initiates an outgoing call (if that extension did not turn block caller-ID on). This model is typically used with customer premises PSTN gateway hardware. However one can link two Bizfon systems together by using gateway trunks as long as they are routable to each other i.e. both are on public IP addresses or a private network.
- Proxy. The proxy model is similar to the gateway model. The difference is the way anonymous calls are made and how the proxy represents its own domain. As the name suggests, the proxy model assumes that you are talking to a SIP proxy, while the gateway model assumes that you are talking to a SIP user agent. However, the two models are quite similar.
Trunks are usually in scope of a domain. But you can also make a trunk visible in all domains. For example, if you want to share a PSTN gateway amongst all domains, you would set up a trunk in a separate domain and make it visible to all domains.
Current Trunks
In the trunk list, you can see which trunks are available in the current domain. If the trunk is a registration, the PBX will show the registration status. A 200 OK is the desired state of the Trunk status. To force a re-registration request of this trunk, you may click on the register link.
To delete a trunk, you may click on the delete icon. To edit the details of a trunk, you can click on the edit icon.
At the bottom of the page you find a form for creating a new trunk. Trunk names may include alphanumeric characters and space. The system assigns a number to each trunk, so that it is ok if different domains choose the same name for a trunk.
Name and Type
After you have created a trunk, you may change the name and the type. The name must consist of alphanumeric characters and may contain spaces. The trunk type can be selected by a selection box.
You may limit the direction of the trunk to accept only inbound traffic, to send only outbound traffic out. Limiting traffic to inbound only avoid that users use trunks for unauthorized calls. For example, when using a trunk for ENUM without outbound proxy, you may want to avoid outbound traffic on that trunk. If you are using a trunk only for outbound traffic, it makes it easier for the PBX if you explicitly set the trunk to outbound only. Then the trunk will not try to match inbound traffic to this trunk.
General Parameters
The "Display Name", the "Account" and the "Domain" are used to construct the address that the PBX registers. The account must be a valid SIP account identifier and the display name is used for display purposes. For example, the display name could be "Test Account", the account "test-account" and the registrar "test.com". Then the PBX would register "Test Account" <sip:test-account@test.com>.
The "Username" and the "Password" are used for authentication purposes. Some registrars use a different username for authentication; therefore the PBX includes this field as well. The password needs to be entered twice, so that accidental wrong entries can be detected.
The "Outbound Proxy" defines where requests of this trunk will be sent. If this setting is set, it will always send requests to this other address. Otherwise, the dial plan replacement field will determine where the request is being sent.
The outbound proxy field follows the definitions of RFC 3263 ("Locating SIP Servers"). In a nutshell, you may use the DNS name for a SIP server. If you put a colon with the port number behind the name, you use only DNS A resolution. Otherwise, the PBX will try DNS NAPTR and DNS SRV first.
The outbound proxy is a important setting. If you don't use an outbound proxy then the PBX will assume that SIP requests on this trunk can come from any location. This will make it difficult for the PBX to match incoming SIP requests. Unless you want to receive requests from any location in the Internet, you should specify an outbound proxy.
The "CO-Lines" and "Dialog Permissions" settings are discussed separately in CO Lines.
If the "Codec Preference" setting is set, the PBX will use a different codec preference on this trunk. By default, the PBX has no specific codecs set specifically for that trunk and it will use the codec preference of the system. You will see no codecs selected on the left side of the codec selection box. This has the advantage that the PBX may negotiate codecs in such a way that transcoding can be avoided.
If you have to enforce specific codecs on a trunk, then you may add them with the "Add" button from the list of available codecs. They will be appended to the list of preferred codecs; so you should add the codec with the highest preference first. In order to delete a codec, click the "Remove" button. If you want to move a codec up or down in the preference list, use the "Up" and "Down" buttons.
According to the IETF standards, the registrar defines the duration of the registration. However, some providers follow the proposed duration of the trunk. Therefore, the PBX includes a "Proposed Duration" which is in seconds. One hour (3600 seconds) is a reasonable value here.
There are some providers that accept the proposed duration, but don't really take care about refreshing the NAT binding. In such a case what you can do is ignoring the service provider's registration duration and force the PBX to renew the registration in a shorter period of time. The setting "Keepalive Time" is used for that. However, this setting may cause a lot of traffic to your service provider, so don't make it shorter than necessary. Typically you can leave it blank.
If you register a trunk, it is quite important to know if a trunk looses the registration. For example, when your service provider goes offline, you would like to get an email about such an event. The PBX will send an email to the administrator account in case that the trunk changes the registration status ("Send email on status change").
The setting "Strict RTP Routing" is necessary, because the IETF allows that RTP traffic send ports may be different from RTP receiving ports. Because this is extremely NAT-unfriendly, today most implementations use the same port number for sending and receiving RTP. However, some gateways still insist on strict IETF compatibility. In this case you need to turn this setting on. Our recommendation is to keep this flag on "no" unless you really need to have asymmetrical ports.
If your registrar does not support UUID (RFC 4122), it usually ignores this unknown additional information. However, some SIP implementations are not able to deal with UUID. In this case, they will report a "Bad Request" to indicate that they were not able to process the request. We added the option "Avoid RFC4122 (UUID)" to explicitly suppress the UUID in REGISTER requests. The UUID is used to indicate that a registration replaces another registration; this is useful to avoid double registration after a restart of the system.
The setting "Accept redirect" is necessary if your trunk should respect redirect codes. By default, this introduces significant security risks, because the PBX cannot determine if these redirects introduce additional costs (redirection to expensive numbers). Therefore, you should turn this flag on 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 PBX with Microsoft Exchange or other Microsoft products like the speech server. You should turn the flag also on when you have a trunk that comes from another or the same PBX in a server farm; this will make it possible to call from one domain to another.
When a call comes in, the PBX needs to know how to interpret the number. In SIP, the URI contain a domain name, which is part of comparisons for example for the address book. However, in most cases, the domain name should be ignored when interpreting the URI coming from this trunk (because the user part is just a telephone number). Usually this indicated with the parameter "user=phone", but there are some service providers that don't sent this flag. By turning the "Interpret SIP URI always as telephone number" you make the PBX believe that this flag was set on the trunk call.
When you are using a analog PSTN gateway (e.g. FXO), you will run into the problem of hangup detection. In FXO, the hangup signal might just be a tone that needs to be detected. Unfortunately, there is no international standard for the disconnect tone; even if you are located in a specific country, incoming international calls might give you a disconnect tone that the system has to recognize. Of course, if your PSTN gateway is capable of detecting this, you should leave this job to the PSTN gateway. As a fallback, you may also ask the PBX to perform the hangup detection. The disadvantage of having the PBX doing this is that it costs additional CPU resources and that you might randomly disconnect calls, for example if the other party is playing back a tone that just sounds like a busy tone. The best way to avoid these kind of problems is to use a digital line, e.g. a SIP trunk.
Outbound Settings
The settings "Prefix" and "Trunk DID" are used for the representation of the PBX when making an outbound call. This topic is covered in Outbound Calls on Trunk.
The "Global" flag is usually used when you have more than one domain. This flag tells the PBX that calls that come in on this trunk can jump into other domains if there is a match on a global alias name (tel:-alias). If the flag is off, the PBX does not search for tel:-alias names. If the flag is set to "on" and the driection is not only inbound, then other domains may use this trunk in their dial plans for outbound calls.
The setting "Remote Party/Privacy Indication" tells the PBX how to present the Caller-ID on the trunk. This setting is discussed in Outbound Calls on Trunk. Please note the "Remote Party/Privacy Indication" field in the latest version setting is default as "RFC3325 (P-Asserted-Identity)", you must change it to "No-Indication" instead.
When you are using a trunk, you might have to represent the telephone number is a specific format. For example, in the NANPA area, you might want to use 10 or 11 digits to represent a national number. If you are using several trunks, you can represent the same number in different styles depending on the trunk.
When the trunk receives an error code, it may send the call back to the dial plan and continue the matching process. The PBX continues the dial plan with the next higher priority; entries with a lower or same priority are not used. This is useful when this trunk is just a "trial" to place the call, for example 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 fall back to a PSTN call. The setting allows three behaviors:
- Never failover. That is the default behavior. In this case, the caller will receive the error code as the result of the call attempt.
- On all error codes. In this case, all error codes will trigger the failover process. Note that also call redirect will be treated as an error code, as the redirection destination can easily be abused to route calls though expensive routes.
- Only 5xx error codes. This will trigger failover only when a 5xx or 6xx class error code is being received. PSTN gateways typically return 5xx class error codes when all channels are in use, and using this mode you can switch to the next PSTN gateway only in this case, while a caller busy will not trigger the failover.
The "Is Secure" flag is available in the professional version and is used to indicate that outbound calls on this 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. In the professional version, incoming calls with the sips scheme ask the PBX to ensure that the call should be kept secure end-to-end.
The "ICID" setting is used in the IMS 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.
Inbound Settings
The setting "Send call to extension" is discussed in the section Inbound Calls on Trunk.
The setting "Assume that call comes from user" is used for trunks that accept redirects (see above). 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.
The "Ringback" feature was introduced to deal with network operators that are obviously not able to deal with early media. Using the 180 Message simplifies the signaling in forking calls scenarios, however, it means 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 to the Media state, which is default and ask the operator to fix their problems with early media.
