Configuration FAQ

When using the Aculab Prosody S:

• the stack follows the SIP V2.0 specification as per RFC3261.
• the stack switches the media streams between calls. This means all calls to bearer networks present as from a UAC rather than a UAS.
• the set of SIP messages supported are the full set of messages required by a fully compliant UAC. In practice REFER and REINVITE will not be sent by the stack.

Within our environment I only want RFC2833 DTMF handling, i.e. I want zero inband DTMF or inband DTMF detection.

Let's say for example that an outbound call is launched with tone detection enabled for the call route, and valid RTP packet(s) containing DTMF are received.

If receiveDTMF is set to:

• RFC2833 - the DTMF will be detected as RFC2833
• Audio - the DTMF will be regenerated in the audio stream

Therefore the answer to the question is: the setting required to ensure zero inband DTMF tone detection is RFC2833.

<enableLoopback>false</enableLoopback>

Does this mean that "internal" destinations such as overflow queues etc remain within Softdial CallGem™ i.e. outbound dialing is rechecked against Softdial CallGem™'s incoming dial plan or something similar?

This setting is a basic sanity check before any outbound call is launched from Softdial Telephony Gateway™ (STG). When set to false (default) it will stop outgoing calls with the same IP address as the STG host. This in effect prevents the STG from calling itself and potentially getting stuck in an infinite call loop situation. When set to true, calls can be sent out of the STG to itself.

<congestionThreshold>5</congestionThreshold>

What codes are classified as congestion?

What happens to the Softdial CallGem™ system when the route is considered congested for 10 seconds? (i.e. does Softdial CallGem™ pause dialing or just return fast busy for all records).

After the 10 seconds, is there any form of dampening or is the route just relaunched straight into full tilt dialing?

Within STG, each call route can have a priority associated with it. If an outbound call has a number that fits the criteria for multiple call routes, the call route with the highest priority will be chosen for the call to be placed first. If this route is deemed to be congested then the congestion counter for this route is incremented and the next highest priority call route is attempted.

A congested outcome is any of the following (currently hardcoded):-

• NoChannelAvailable
• TemporaryFailure
• SwitchingEquipmentCongested
• RequestedChannelNotAvailable
• SIP_ServiceUnavailable
• NetworkOutOfOrder
• SIP_NotFound

Each congested outcome added to the list for a route is time-stamped. When that outcome is more than 10 seconds old it is removed from the list.

When the congested route becomes uncongested, and assuming this is the highest priority route, calls will again be presented to this route. If the route becomes congested again then calls will be switched to another route thereby providing a form of self dampening until the congested route capacity is fully restored.

reservedIncoming
This is number of DSP channels being allocated/ reserved (put into waiting state) for Incoming calls on STG startup. It doesn't limit number of incoming calls (i.e. if it is set to 10, and there are already 10 incoming calls in progress, an 11th DSP channel, if available, would be allocated/ reserved for any other potential incoming call, and so on), but ensures that DSP channels are allocated for the configured number of incoming calls even if all channels would otherwise be used for outbound calls.

maximumInboundCalls
This limits number of simultaneous incoming calls STG would accept in any circumstances.

STG has a very flexible dial plan; this can sometimes lead to making address mappings that solve local issues but prevent the dial plan from having general-purpose rules.

The best way to manage the dial plan in STG is to have all incoming addresses resolve to telephone digits and configure route table entries to add necessary SIP decoration.

On input, to undecorate SIP addresses, each STG should have the following input address translations:

<addressTranslations>
  <translate address="sip:*@<my.host.ipv4.address>" translated="*" />
  <translate address="sip:*@<my.public.sip.dns.name>" translated="*" />
  <translate address="sip:*@sip.mcast.net" translated="*" />
  <translate address="sip:*@224.0.1.75" translated="*" />
  <translate address="sip:*@<my.internal.sip.proxy.ip.address>" translated="*" />
  <translate address="sip:*@<my.sbc.ip.address>" translated="*" />
  <translate address="sip:*@<any.other.stg.in.my.cluster.ip.address>" translated="*" />
</addressTranslations>

The above config substitutes values for the STG host address and addresses of local proxies, Session Border Controllers (SBCs) and other STG hosts. Within an organisation there may be multiple SBCs and SIP proxies. Any SIP device that has a direct relationship with STG should have an entry converting the SIP URI to a telephony address.

The route table examples in the base STG config have sample setups for PSTN, international, emergency and phone extension routes. By using prefix and postfix, the dialed number can be turned into a valid SIP URI to go to the right destination.