Outbound Route Configuration
Outbound routes may be configured within the STG config.xmlfile.
Example <route> configuration
<route name="PBX">
<targetPortGroups>
<portGroup>TRUNKS</portGroup>
</targetPortGroups>
<acceptList>
<item></item>
</acceptList>
<maxCalls>360</maxCalls>
<stripPrefixes>
<item></item>
</stripPrefixes>
<rejectList>
<item></item>
</rejectList>
<tenantList>
<item>default</item>
</tenantList>
<prefix>sip:</prefix>
<postfix>@%%defaultSipProxy%</postfix>
<maxDigits>4</maxDigits>
<minDigits>4</minDigits>
<allowCallProgressEmulation>true</allowCallProgressEmulation>
<ipCallProfile>Agents</ipCallProfile>
<presentation>
<originating_addr>sip:PSTN@%%myfqdn%</originating_addr>
</presentation>
<priority>1</priority>
<congestionThreshold>5</congestionThreshold>
<cadenceRule>UK</cadenceRule>
</route>
Below is a detailed description of the elements of an outbound <route> configuration.
Show element descriptions
| Element | Description | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| <targetPortGroups> | A list of <portGroup> elements that this route should use. Port groups are defined in the <portGroups> element in the Ports section of the STG config.xml file) |
||||||||||||||||||||||||||||||||||||||||||||||||
| <acceptList> | A list of <item> elements interpreted as "If the number doesn't begin with at least one of these, reject it from this route". If <acceptList> is not provided, then all numbers are accepted. See Accepting/ rejecting calls of specific types below. See also <rejectList> below |
||||||||||||||||||||||||||||||||||||||||||||||||
| <maxCalls> | An integer value to define how many calls are allowed through the route. See Specifying gateway capacity below. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <stripPrefixes> | A list of <item> elements scanned to remove any listed prefix from the number/ address. Only the first matching prefix will be removed. See Adding/ removing prefixes below. See also <prefix> below. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <rejectList> | A list of <item> elements interpreted as "If the number begins with one of these, reject it from this route". Checking is done after the <acceptList>, so that you can, for example, accept all numbers beginning with 0, except numbers beginning with 00. See Accepting/ rejecting calls of specific types below. See also <acceptList> above. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <tenantList> | A list of <item> elements for which the route is valid. If the <tenantList>
|
||||||||||||||||||||||||||||||||||||||||||||||||
| <prefix> | Characters to be appended to the start of the number/ address, e.g.<prefix>sip:</prefix> See Adding/ removing prefixes below. See also <stripPrefixes> above. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <postfix> | Characters to be appended to the end of the number/ address. Can be used to specify a gateway per route. See Routing to multiple gateways below. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <maxDigits>
<minDigits> |
If the number is too long/ short, it is rejected by this route and the next route will be tried | ||||||||||||||||||||||||||||||||||||||||||||||||
| <allowCallProgressEmulation> | When <allowCallProgressEmulation> is set to true, if a call fails while the agent is connected, with a digital signal (e.g. 'busy') and is terminated, then call progress (tone) emulation allows for a WAV file to be played to the agent, to give an audio indication of progress. The signal to WAV file mappings are defined in the <callProgressEmulation> element, in the Progress Indicators section of the STG config.xml file. Without the emulation, the agent would only hear inband audio progress tones from the call being dialed before the call ends. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <ipCallProfile> | The call profile to use for this route. <ipCallProfiles> are set in the Call Profiles section of the STG config.xml file |
||||||||||||||||||||||||||||||||||||||||||||||||
| <presentation> | A set of optional setup elements defining the appearance at the receiving end of an outgoing call.orig_numbering_type A valid Q.931 numbering type for the call which must be appropriate for the signalling system. Allowable values are:
Some signalling systems may not have support for all these values. The default value is 0 (NT_UNKNOWN). orig_numbering_planA valid Q.931 numbering plan for the call which must be appropriate for the signalling system. Allowable values are:
Some signalling systems may not have support for all these values. The default value is 0 (NP_UNKNOWN). orig_numbering_presentationIndicates the intention of the calling party for the presentation of the calling number (originating_addr) to the called party. Allowable values are:
orig_numbering_screeningAllowable values are:
originating_addrThe calling address sip_contactA single SIP URI for the Contact header field that can be used to contact the sender of the INVITE for subsequent requests. The Contact header field MUST be present and contain exactly one SIP URI in any request that can result in the establishment of a dialog. |
||||||||||||||||||||||||||||||||||||||||||||||||
| <priority> | Indicates the priority that STG will distribute calls to the routes. See Load balancing between routes below |
||||||||||||||||||||||||||||||||||||||||||||||||
| <congestionThreshold> | Used by STG to determine how many calls must fail on account of congestion on a route before that route is put "out of service" for a period of 10 seconds to allow the route to decongest. Default value is 5. Currently a call is deemed to have failed on account of congestion if one of the following clearing causes has been received from the network:
|
||||||||||||||||||||||||||||||||||||||||||||||||
| <cadenceRule> | The cadence rule to use for this route. A cadence rule is a particular set of characteristics describing the pattern of SIT tones used in each territory. See SIT tone detection strategies. Cadence rules may be set in the <cadenceRules> element, in the Tone Detection section of the STGconfig.xml file |
Below are some usage examples for configuration when using
- multiple gateways (gateway clusters)
- single gateways with multiple routes configured
Routing to multiple gateways
To direct calls passing through each individual route to a specific gateway, a postfix can be applied.
Example 1
| Route | Configuration |
|---|---|
| R1 | <postfix>@gateway1.co.uk</postfix> |
| R2 | <postfix>@gateway2.co.uk<postfix> |
where gateway1.co.uk and gateway2.co.uk are valid IP addresses of two separate gateways.
Example 2
To route UK calls to a UK Sip service, and Polish calls to a Polish SIP service, the following configurations may be used:
<route name="UK">
...
<acceptList>
<item>0044</item>
<item>44</item>
</acceptList>
<postfix>@SIPServiceUK</postfix>
<presentation>
<originating_addr>UKCLI</originating_addr>
</presentation>
<cadenceRule>UK</cadenceRule>
...
</route>
<route name="PL">
...
<acceptList>
<item>0048</item>
<item>48</item>
</acceptList>
<postfix>@SIPServicePL</postfix>
<presentation>
<originating_addr>PLCLI</originating_addr>
</presentation>
<cadenceRule>Poland</cadenceRule>
...
</route>
Specifying gateway capacity
The <maxCalls> element may be used to specify the capacity (i.e. number of channels) of each gateway.
For example, there may be two gateways being used, each connected to a differing number of E1/T1 lines.
Two routes can be specified that match the same calls but each route directs calls to a different gateway. By giving both routes the same priority, calls will be distributed randomly between them.
As they have differing maximum capacities, use <maxCalls> to specify the capacity (i.e. number of channels) of each gateway.
Resources (channels) are marked as in use when a call is dialled via a route and released when the call goes idle.
If all of the resources available in a <route> are in use when a new call is launched, then the route is removed from the list of routes available for the call.
Adding/ removing prefixes
Each route can be configured to apply separate prefixes and/ or strip prefixes from the numbers that pass through them.
Route translations are performed after address translation.
Example
To set a rule stating If number begins with 06, then replace 06 with +316, set a route which includes...
<stripPrefix> 06 </stripPrefix>
<prefix> +316 </prefix>
So 0612345678 would become +31612345678
Accepting/ rejecting calls of specific types
If you always want to use a specific route for a specific type of call (e.g. you will always nail up agents through route R1), then this can be achieved by
- adding item(s) to the accept list of that route, and
- adding the same item(s) to the reject list of all other routes
Example
If we only want to nail agents up through route AgentRoute, where we know all agent extension numbers are of the format sip:agentExample@ipaddress, then we could use the following configuration:
<route name="AgentRoute">
...
<acceptList>
<item>sip:agent</item>
</acceptList>
...
</route>
<route name="IPDialout">
...
<rejectList>
<item>sip:agent</item>
</rejectList>
...
</route>
Load balancing between routes
Use the priority value to indicate the priority that STG will distribute calls to the routes.
Example
Given the following route settings:
| Route | Priority |
|---|---|
| R1 | <priority>1</priority> |
| R2 | <priority>3</priority> |
STG will first try to launch calls through R1 and, if that is not possible, then through R2, provided that all of the other route criteria have been met (i.e. call is in acceptList, call is not in rejectList, route is valid for the current time and date, etc).
Two routes are allowed to have the same priority.
If a route is given priority 0, (which is the default priority), it is the only route that will be used for any valid calls.
Handling congestion
Use the congestionThreshold to set how many calls must be congested on a route before that route is put "out of service" for a period of 10 seconds to allow the route to decongest. Default value is 5.