Introduction
A typical installation of the jtel system consists of one or more telephony and application servers to provide services to its users.
Trunks and Trunk Groups are the logical way telephony resources are organised and connected to the system and it servers.
Trunks
The telephony server provides SIP connectivity at the base level for a certain number of channels. When using SIP, each telephony server has one SIP connection (usually UDP on port 5060), which is capable of addressing any remote telephony service using a domain name or an IP address. This SIP connection is known as a Trunk.
On an ISDN based machine, there may be more than one trunk, for example one for each primary rate connection the system provides. Each of these connections is an individual trunk on a particular server.
Trunks are configured using the System Settings ... Trunks menu, and the following fields are configured:
| Field | Description |
|---|---|
| MachineID | Each telephony server has a unique ID within each installation. This is assigned in the telephony server system settings menu, under the option "General". As a convention, we recommend that the final number of the IPv4 address is used. This number must match the number assigned in the trunk for the system to be able to select and identify trunks appropriately. |
| Controller | Each SIP controller has a unique ID. This is configured in the files giAculab.cfg and StdCall_MCP.cfg in the telephony server. In giAculab.cfg numbering starts at 0, wheras in the jtel telephony server, numbering starts with 1. Usually, the SIP provider will be configured as netport 0 in giAculab.cfg and Controller 1 in StdCall_MCP.cfg. |
| Name | The trunk can be given a descriptive name for identification purposes. |
Trunk Groups
Trunk groups affect how numbers are translated when incoming calls are received, and how numbers are translated and various call control parameters are provided, when outgoing calls are made.
When incoming calls are reveived, the first task the system undertakes is to match the incoming call to a particular trunk. This may be used to identify the service number, and the trunk will be used in all further interaction with the telephony layer. When outgoing calls are made, trunk groups are used to select an available server and trunk from those available, and set parameters in the telephony layer (for example SIP header fields) when the call is made.
In a SIP based installation, each trunk will be assigned to one or more trunk groups. In an ISDN based installation, trunk groups may contain more than one trunk. Trunk groups may contain trunks from more than one telephony server, to enable load balancing and selection of trunks for outgoing calls over more than one server.
The following tabs and fields are available:
Master Data
This page contains the parameters for the trunk group, and affects how translation and matching to the trunk group is done.
The following fields are configured:
| Field | Description |
|---|---|
| ID | An automatically assigned ID from the system. |
| Name | A descriptive name for the trunk, which is used when selecting the trunk when configurations are made, for example in service numbers. |
| Incoming Number Pattern | Trunk groups can be matched based on the called number. For example, 49894614950% would match all incoming calls to the jtel main office in Munich. |
| SIP Source Server | Trunk groups can alternatively be matched based on the SIP source and destination server in the SIP From: and To: headers. This field affects the From: header match. Any match can be made here, but it is worth checking whether the incoming INVITE messages contain IP addresses or names (DNS) using wireshark. |
| SIP Destination Server | See SIP Source server. This field affects the To: header match. |
| SIP Invited Entity | Trunk groups can be matched on the invited entity in the INVITE message line (first line in the INVITE message). |
| Subscriber Country Code | For some number translators, the location of the system is used when converting numbers. This parameter is used to match the country code. For example, for jtel, 49 for Germany. |
| Subscriber Area Code | For some number translators, the location of the system is used when converting numbers. This parameter is used to match the area code. For example, for jtel, 89 for Munich. |
| Subscriber Prefix | For some number translators, the location of the system is used when converting numbers. This parameter is used to match the prefix (head number) of the system. For example, for jtel, 4614950, for the head number of the PBX. |
Order of Matching
The following order of matching applies, the first trunk group found applies:
| Direction | Matching Order |
|---|---|
| Inbound | Incoming calls are routed to a particular telephony server by a PBX or SIP entity outside the scope of this document. It is recommended, that when more than one telephony server is present, load sharing between the active servers be configured. Also, it is important to note, that the reception of a TRYING in response to an INVITE does not indicate success, but only that matching process will be initiated. Additional steps should be taken on the providing server to ensure that after a timeout, the call is distributed to another server if at least not a final response, or a RINGING are received. Matching then takes place as follows:
|
| Outbound | First of all the telephony server is selected according to a "least used but active" convention. This means the telephony server must have set a keep alive timestamp in the system database. The active server with the least number of calls will be used. Next, the trunk group is matched as follows:
|
Trunks
This page is used to assign trunks to the trunk group.
When trunk groups are matched, the first criteria is always whether one or more trunks are configured and match on the target telephony server. When an incoming call is received, the Controller and Machine ID are available to the telephony server, which identifies a particular Trunk. Only trunk groups to which this trunk is assigned, will match. When outgoing calls are made, the system will select a telphony server based on a least used algorithm, and a trunk according to the system configuration (general access or a specific trunk assigned to the client account). The telephony server selected must have a trunk available on the trunk group determined to be used, otherwise the outbound call will fail.