Introduction

The advanced configuration options can be configured under "more" in the SIP configuration, the ISDN / Analog / LTE / GSM Group Configuration and in the Dialplan. The dialplans advanced configuration options will always overwrite the ones configured in the SIP or PSTN Groups. 

ISDN specific config options

TON Settings

Numbers in ISDN messages have a flag attached, telling about the number format, called Type Of Number. The Following TONs are available:

• TON_UNKNOWN=0

• TON_INTERNATIONAL=1,

• TON_NATIONAL=2,

• TON_NETSPECIFIC=3,//==local type of number

• TON_SUBSCRIBER=4,//==private type of number

• TON_ALPHANUMERIC=5,

• TON_ABBREVIATED=6,

Following config values are used for setting specific TONs

• oton: TON of the OAD, default: oton=4

• o2ton: TON of the second OAD, default: o2ton=4

• dton: TON of the DAD, default: dton=0

• cton: TON of the CAD, default: cton=0

• rton: TON of the RAD, default: cton=0

TON Prefixes

On Inbound ISDN calls, the ISDN numbers can be prepended by a string based on their associated TON flag. The config value prefix_priority determines if the prepending of the prefix should be performed before or after dialplan mangling.

• unknownprefix : prefix for ton unknown, default=

• nationalprefix : prefix for ton national default=0

• internationalprefix : prefix for ton international default=00

• localprefix : prefix for ton netspecific default=

• privateprefix : prefix for ton subscriber default=

• alphanumericprefix : prefix for ton alphanumeric default=

• abbreviatedprefix : prefix for ton abbreviated default=

NPI Prefixes

Additionaly to the Type of Number an ISDN Number has an associated Numbering Plan flag.

• onpi: Numbering Plan for the OAD, default=1

• o2npi: Numbering Plan for the second OAD, default=1

• dnpi: Numbering Plan for the DAD, default=1

• rnpi: Numbering Plan for the RAD, default=1

• cnpi: Numbering Plan for the CAD, default=1

Screen and Presentation Settings

• screen:

• screen2:

• pres:

• pres2:

Outgoing B-Channels

outgoing_bchannels: accepts a dot separated list of allowed bchannels and bchannel ranges for outgoing ISDN calls.

e.g.:

outgoing_bchannels=13.19-21

will use either b-channel 13, 19, 20 or 21.

If none of these channels are available, the call will be not executed.

Channels must be in valid range, if any none-valid channel is given, this option will not be applied and all channels will be allowed.

bearer_codec

bearer_codec configures the bearer codec used in the bearer capability information element. It can take the values: alaw, ulaw or g722. The default is alaw.

SIP Header Settings

sip_pai_all_setting

sip_pai_all_setting can be set to a freely definable string which then will be used as content of the P-Asserted-Identity Header.

Following variables can be used in the string:

• ${new_source}

• ${new_destination}

• ${oad}

• ${oad2}

• ${clip}

• ${cnip}

• ${qsigname}

• ${account_username}

• ${isdn_uuname}

• ${isdn_display}

sip_pai_user_setting

If sip_pai_all_setting is not set and sip_pai_user_setting is set, the P-Asserted-Identity Header will be set using this value as the user name.

sip_pai_display_setting

If sip_pai_all_setting is not set and sip_pai_display_setting is set, the P-Asserted-Identity Header will be set using this value as the display name.

sip_pcpi_all_setting

Same as sip_pai_all_setting, but for the P-Called-Party-ID Header.

sip_pcpi_display_setting

Same as sip_pai_display_setting, but for the P-Called-Party-ID Header.

sip_pcpi_user_setting

Same as sip_pai_user_setting, but for the P-Called-Party-ID Header.

sip_ppi_all_setting

Same as sip_pai_all_setting, but for the P-Preferred-Identity Header.

sip_ppi_display_setting

Same as sip_pai_display_setting, but for the P-Preferred-Identity Header.

sip_ppi_user_setting

Same as sip_pai_user_setting, but for the P-Preferred-Identity Header.

sip_rpi_all_setting

Same as sip_pai_all_setting, but for the Remote-Party-ID Header.

sip_rpi_display_setting

Same as sip_pai_display_setting, but for the Remote-Party-ID Header.

sip_rpi_user_setting

Same as sip_pai_user_setting, but for the Remote-Party-ID Header.

sip_contact_all_setting

Same as sip_pai_all_setting, but for the Contact Header.

sip_contact_display_setting

Same as sip_pai_display_setting, but for the Contact Header.

sip_contact_user_setting

Same as sip_pai_user_setting, but for the Contact Header.

sip_priv0_all_setting

With the sip_priv0_all_setting you can add a custom header to an outgoing INVITE. 

Examples:

If you send an INVITE to a SIP peer configured with account username user123:

sip_priv0_all_setting=P-Special_Header: ${account_username}

would add a header:

P-Special_Header: user123

to the outgoing Invite.

If you send an INVITE to the SIP peer configured with account username user123 at address 192.168.2.1:

sip_priv0_all_setting=P-Custom_Header: ${account_username}@${account_domain}

would add a header:

P-Custom_Header: user123@192.168.2.1

to the outgoing Invite.

If this is for a ISDN->SIP call with dad 12345 and oad 6789:

sip_priv0_all_setting=P-Custom_Header2: ${dad}@${account_username};isdn_oad=${oad}

would add a header:

P-Custom_Header2: 12345@192.168.2.1;isdn_oad=6789

On a SIP->SIP call where the first leg gets an INVITE with from display Jane Smith and a to user 900:

sip_priv0_all_setting=P-Custom_Header3: <${from_display}> ${to_user}@${account_domain}

would add following header to the outgoing Invite:

P-Custom_Header3: <Jane Smith> 900@192.168.2.2

On a SIP->SIP call where the first leg gets an INVITE with a P-Preferred-Identity Header, e.g.

P-Preferred-Identity: <sip:123@example.com>

setting the config option:

sip_priv0_all_setting=P-Custom_Identity: ${ppi_all}

would add following header to the outgoing Invite:

P-Custom_Identity: <sip:123@example.com>

Possible values for the variables are:

• ${new_source}
• ${new_destination}
• ${new_destination_auto}
• ${dad}
• ${oad}
• ${oad2}$
• ${clip}
• ${cnip}
• ${qsigname}
• ${account_username}
• ${isdn_uuname}
• ${isdn_display}
• ${account_base_number}
• ${account_base_number_auto}
• ${from_user}
• ${from_display}
• ${pai_all}
• ${pai_user}
• ${pai_display}
• ${ppi_all}
• ${ppi_user}
• ${ppi_display}
• ${rpi_all}
• ${rpi_user}
• ${rpi_display}
• ${pcpi_all}
• ${pcpi_user}
• ${pcpi_display}
• ${request_url_user}

Beware, some of these variables are only available when using a certain technology, and maybe empty nonetheless.

There are additional config options named sip_priv1_all_setting to sip_priv9_all_setting, with which you can add additional custom headers.

header_passthrough

If header_passthrough=1 is set, all headers on a SIP→SIP call, which have not been explicitly set, are passed through transparently to the target destination.

header_passthrough_filter

This setting can be used, if header_passthrough=1 has been set. If it is empty (default) all headers are passed through. Otherwise it expects an regular expression, filtering which headers are passed through.

E.g.

header_passthrough_filter=^X-|^Remote

would only pass through Headers which start with X- or Remote.

Other config options

dgain_packet_to_pcm

Sets the Volume level in the direction IP to TDM, valid values are "-14.0 to +6.0 dB (range -140 to +60)"

Default is 0

dgain_pcm_to_packet

Sets the Volume level in the direction TDM to IP, valid values are "-14.0 to +6.0 dB (range -140 to +60)"

Default is 0

ec

Enables or disables the configured echo canceller on voice channels, can be 0 (disable echo canceller) or 1 (use echo canceller).

Default is 1.

ectl

Echo canceller tail length. Can take a value between 0 and 15 (default). 0=8ms,1=16ms,2=24ms,...,15=128ms

ec_sparse_params

Allows to set additional echo canceller parameters, if the default echo canceller is used. Following parameters can be configured.

• (0) Echo Canceller DC Removal Filter Disable:

• enabled=0 (default)

• disabled=1

• (1) G168 EC Initialization Register Reset:

• begin initialization=1 (default)

• initialization finished=0

• (2) Initialization Request: initialization request:

• reset echo canceller variables=1 (default)

• reset echo canceller variables=0

• (3) Hardware Echo Canceller Coefficient Freeze:

• 0=allow update of coefficients (default)

• 1=disable update

• (4) Non Linear Processor Control:

• 0=enable NLP control (default)

• 1=disable NLP Control

• (5) Non Linear Processor Tune Field:

• 0=normal nlp engagement (default)

• 1=reduced engagement

• 2=enhanced engagement

• try out reduced NLP engagement when you hear artifacts like choppiness

• try out enhanced NLP engagement when there is a larger non linear component (e.g. on some 2- or 4-wire lines)

• (6) Comfort Noise Generation Disable:

• 0=CNG enabled (default)

• 1=CNG disabled

When this option is not giving, the default values apply.

The syntax to override the default values with this command is in the form of a set of pipe separated index:value tuples. E.g.:

ec_sparse_params=5:1|6:1

sets Non Linear Processor Tune Field (index 5) to reduced engagement, and disables Comfort Noise Generation (index 6).

feature_codes

With feature codes, certain events can be triggered during an active call by a sequence of user defined DTMF tones.

Each feature code is a colon separated set of three values: DIRECTION:DTMFSEQUENCE:EVENT

• DIRECTION can be either 't' or 'f' or 'b', standing for to, from or both directions.

• DTMFSEQUENCE is a sequence of DTMF tones sent by the corresponding partys.

• EVENT is the action that will be triggered.

If more than one feature code has to be used, they have to be separated by a semicolon.

Following Events can be triggered.

• afh: Analog Flashhook (FXO)

• mcid: Malicious Call Identification (ISDN TE)

Examples: To trigger a Flashhook on a SIP to ANALOG FXO call with a '#' digit:

feature_codes=f:#:afh 

To trigger a Flashhook on ANALOG FXO to SIP call with a '123' digit sequence:

feature_codes=t:123:afh

To trigger a Flashhook on an ANALOG FXO call with a '#' digit in both directions:

feature_codes=b:#:afh 

dialplan_go_on

Can be set in a SIP->PSTN dialplan rule.

If dialplan_go_on=1 and the rule matches, but there are no free PSTN ports in the set of ports defined by to_id, then continue searching through the dialplan on the next line.

If dialplan_go_on=0 (default behaviour), a corresponding reject cause (can be defined in the causes map) will be sent into SIP direction.

aoc: AOC (Advice of Charge) generation

The aoc definition up to the first vertical bar defines the type of aoc generation.

ISDN: If AOC Currency should be used, the first field has the syntax: CUR:$CURRENCY:$MULTIPLIER, where $CURRENCY is the currency string to be displayed and $MULTIPLIER denotes the multiplier to be applied to the currency unit multiplier can be a number between 0 and 6 (0=1/1000, 1=1/100, 2=1/10, 3=1, 4=10, 5=100, 6=1000)

If AOC Charging Unit shall be used, the first field only needs to be the string CHU.

Analog FXS: If a 12 kHz pulse tone should be used the first field has to be analog12k, for 16 kHz pulse tone set it to analog16k (DOES NOT WORK AT THE MOEMENT FOR FXS)

After the type of AOC definition comes the definition of intervals and actual units.

The syntax is a series of AOC charge/interval/repeat descriptions separated by vertical bars:

An AOC event is a colon separated triplet of:

1. Amount of charge units (for analog this any value will be converted to 1)

2. Interval

3. Number of repeats

AOC generation starts on on call connect.

Examples of charge/interval/repeat dseparatedefinitions:

charge one unit every 30 seconds, until end of call

1:30:-1

the first 60 seconds are charged with 2 units, then charge one unit every 30 seconds until end of call

2:60:0|1:30:-1

the first 300 seconds are charged with 1 units every 30 seconds, after this nothing will be charged anymore

1:30:10|0:0:-1

Examples of possible config values

ISDN AOC Currency: Charge 2 EUR every 60 seconds (multiplier is 1)

aoc=CUR:EUR:3|2:60:-1

Charge 0.2 EUR every 60 seconds (multiplier is 1/1000)

aoc=CUR:EUR:0|20:60:-1

AOC Charging Unit: Charge two units in the first minute, then one unit for every following minute

aoc=CHU|2:60:0|1:60:-1

faxdetect_options

faxdetect_options lets you control some basic parameters regarding PSTN side FAX detection and can be used to reduced false positive fax tone detections.

faxdetect_options takes up to six colon separated parameters:

• connect_window (default=10) : specifies the time in seconds in which fax detection is active after call connects

• min_events (default=1) : specifies the number of fax tones to detect to be considered a FAX call

• min_tonelength (default=400) : specifies the minimum length of fax tone to be considered a FAX tone

• max_tonelength (default=600) : specifies the maximum length of fax tone to be considered a FAX tone

• min_interval (default=2500) : specifies the minimum interval time between two FAX tones to be accepted

• max_interval (default=3500) : specifies the maximum interval time between two FAX tones to be accepted

If not all values are passed, the defaults apply.

The default for faxdetect_options is:

faxdetect_options=10:1:400:600:2500:3500

To disable fax tone detection, set:

faxdetect_options=0

rtp_loopback

on a PSTN->SIP/SIP->PSTN call if rtp_loopback=1, loop back PSTN audio to origin, default=0

rtp_traffic_check

can be 0 or 1, checks every 5 seconds if RTP traffic has been received, otherwise disconnects call

wait_for_cancel

If wait_for_cancel=1 and a SIP->PSTN call is terminated during call setup, the call will not be automatically terminated, but waits for the caller to cancel the call.

Usually this is used on a SIP->ISDN call to receive the inband information after a ISDN DISCONNECT message. Default wait_for_cancel=1

dtmfdpar

dtmfdpar controls some aspect of the built in dtmf detector. It takes up to three colon separated integers.

The first value is the minimum_valid_tone_on_time, the second is the minimum_valid_tone_off_time, the third is the minimum_valid_tone_dropout_time.

To detect a valid digit, the tone must be active for at least the minimum valid tone on time. It must be followed by a period of silence that lasts at least the minimum valid tone off time. If the tone disappears, then comes back within the maximum valid tone dropout time, the tone is considered to still have been active during the dropout time when calculating whether the on time is valid or not.

When not set otherwise the default value is equivalent to dtmfdpar=30:35:20

faxdetect_extension

Can be used on PSTN->SIP calls. If the call is connected, and it is detected that it is a FAX call, the current SIP leg will be aborted and a new SIP call with the given faxdetect_extension as to_user will be started. Dialplan variables can be used, e.g. ${new_destination}.

faxdetect_proxy

If faxdetect_extension is set, this config option can be used to select a different configured proxy to send the SIP request to.

ntdet_params

The ntdet_params option can be used to fine tune the non-tonal energy detector, which is used to detect far end offhook on analog lines. Non-tonal events. e.g. voice, trigger an event, which can be handled in a SIP to FXO call progress table.

It takes a colon separated triplet of integers, the default is 320:30:180

The first value is the energy detector minimum level and can take values from 220 to 420, corresponding to detection levels of -22.0dBm0 (220) to -42.0dBm0 (420)

The second value is the tone measurement period and can take values from 20 to 200 in steps of 5, corresponding to values of 20ms (20) to 200ms (200)

The third value is the tone detector minimum signal to noise ratio and can take values from 100 to 200, corresponding to 10.0dB (100) to 20.0dB (200).

s2fxo_cpt

sip to fxo call progress table

3 Timers can be set in the call progress table, all times are in milliseconds:

default values:

TIMER_DIAL=10000
TIMER_POLREV=10000
TIMER_ALERTING_STOP=-1

TIMER_DIAL is started after dialing is finished, default is 10 seconds. TIMER_POLREV is started after polarity reversal has been detected, default is 10 seconds. TIMER_ALERTING_STOP is started after ring tone has been detected, and is refreshed as new ring tones are detected. default is -1, which means to set the interval automatically from the ring tone definition, and is the time of the full ring tone cadence plus 500 ms, so it triggers when no ring tone has been detected in a full cadence. It can be set to a custom value.

Following events can be converted to SIP events:

DIALING_FINISHED: is triggered as soon as outbound number has been dialed. (starts TIMER_DIAL)

DIALING_FINISHED_TIMER: is triggered as soon TIMER_DIAL runs out.

POLREV: is triggered as soon a polarity reversal is detected. (starts TIMER_POLREV, stops TIMER_DIAL)

POLREV_TIMER: is triggered as soon TIMER_POLREV runs out.

ALERTING_STARTED: is triggered as soon as a ringback tone is detected (stops TIMER_DIAL and TIMER_POLREV).

ALERTING_STOPPED: is triggered as soon TIMER_ALERTING_STOP runs out.

FAR_END_OFFHOOK_DETECT: is triggered as soon as a non tonal energy has been detected. The non tonal energy detector can be configured with config option ntdet_params.

Otherwise the table has the syntax as the SIP to ISDN call progress table, 3 columns (in_event,out_event_out_text)

Example:

[s2fxo:test]
TIMER_POLREV=20000
TIMER_DIALING=10000

DIALING_FINISHED   183_SDP PROCEEDING_DF
DIALING_FINISHED_TIMER NOTHING 
POLREV 200 POLREV_OK
ALERTING_STARTED   180_SDP RING
ALERTING_STOPPED   200 ALERTING_STOP_OK
FAR_END_OFFHOOK_DETECT 200 FAR_END_OFFHOOK_OK

The default table does send a connect as soon as dialing is finished:

[s2fxo:default]
DIALING_FINISHED   200 OK
DIALING_FINISHED_TIMER NOTHING 
ALERTING_STARTED   NOTHING 
ALERTING_ENDED NOTHING 
POLREV NOTHING 
POLREV_TIMER   NOTHING
FAR_END_OFFHOOK_DETECT NOTHING

srtp_mode

srtp mode can be either off, mandatory or optional.

• If off is selected, no srtp is performed, incoming SAVP/RTP Invites will get rejected, if they don't have AVP/RTP as well. Outgoing Invites are AVP/RTP without a crypto line.

• If optional is selected, srtp is performed when possible. Incoming AVP/RTP Invites will managed with or without srtp, depending if a crypto line was offered. Outgoing Invites are AVP/RTP and contain a crypto line in the offer.

• If mandatory is selected, srtp will performed, if it is not possible the call will get rejected. Incoming calls with SAVP/RTP will get accepted, incoming calls with AVP/RTP will get accepted if the offer contains a crypto line. Outgoing Invites are SAVP/RTP.

srtp_crypto_suites

srtp_crypto_suites is used to define the allowed crypto_suites which will be offered and accepted. Following values are possible

• AES_CM_128_HMAC_SHA1_32 (or synonymously AES_CM_32)

• AES_CM_128_HMAC_SHA1_80 (or synonymously AES_CM_80)

• F8_128_HMAC_SHA1_80 (or synonymously F8_80)

More than one value is possible by using a colon as separator, the default is: srtp_crypto_suites=AES_CM_32:AES_CM_80:F8_80

extra_filter

extra_filter can be used in the dialplan to specify a range of additional dialplan matching criteria.

following options are available:

• bearer.cap (compares bearer info capability in ISDN setup with given value)

• bearer.rate (compares bearer info rate in ISDN setup with given value)

• bearer.mode (compares bearer info mode in ISDN setup with given value)

• bearer.user (compares bearer info user in ISDN setup with given value)

• ecall (compares ecall bit in USERUSER information contained in ISDN setup with given value, checks for validity of structure of USERUSER information), only in 2.3-sp2-centersystems-rc1 (or greater)

• ecall.simple (compares ecall bit in USERUSER information contained in ISDN setup with given value, just checks the bit), only in 2.3-sp2-centersystems-rc1 (or greater)

A value of -1 always matches, which is also the default for each of these options. Multiple filters can be appended by separating them with a colon

Example:

Picture three dialplan ISDN->SIP rules, each containing one of the following dialplan config options:

1. extra_filter=ecall=1
2. extra_filter=ecall=0
3. extra_filter=ecall=-1

• If an ISDN SETUP without USER_USER information arrives, the first two rules wouldn't match, but the third one would.

• If an ISDN SETUP with USER_USER information arrives, but USER_USER information structure doesn't follow the "TR Notruf Spezifikation", the first two rules wouldn't match, but the third one would.

• If an ISDN SETUP with USER_USER information arrives and USER_USER information structure follows the "TR Notruf Spezifikation", the first rule would match, if the ecall_bit is set to 1, the second one would match if the ecall bit is 0. The third rule will match both cases.

I.e., by configuring the new_destination for each of the three cases differently, one can now route the calls depending to different destinations, depending whether the extra_filter applies or not.

facility_passthrough

If facility_passthrough=1, ISDN facility events are passed through on a bridged call. This is used, when the SIP server doesn't pass through SIP INFO messages, which are used otherwise by the beroNet VoIP gateway to pass through ISDN FACILITY events.

Example:

An ISDN-SIP rule matches on the gateway and sends an INVITE to an asterisk PBX, and the asterisk sends another INVITE back to the gateway resulting in a SIP->ISDN call.

As soon as the calls are connected, asterisk usually sends a re-invite, effectively bridging the audio on the gateway.

When this happens, the gateway knows the two call legs are related, and bridges the audio locally.

In this scenario, if facility_passthrough=1 is set, ISDN FACILITY message arriving on one call leg, are directly passed through to the ISDN of the other call leg.

Facilities can be passed through, as soon as the call legs are identified of belonging together (by RE-INVITE SDP).

Any Facility message which comes before the bridging of audio will not be passed through, because the call legs cannot be identified of being related before this happens.

Beware, if this option is activated and the SIP PBX actually relays the SIP INFO messages, this may lead to sending out the same FACILITY event two times.

sip_info_on_facility

If sip_info_on_facility=1, contents of incoming ISDN facility messages will be encoded and sent via a SIP INFO message containing a X-BF_FACILITY header.

sip_info_on_disconnect

If sip_info_on_disconnect=1, a SIP INFO message will be sent instead a BYE on a ISDN to SIP call.

sip_xheaders

sip_xheaders defines a set of additional xheaders which will be sent in a SIP INVITE or a response to a SIP INVITE

Following values are possible (which can be combined by using a colon as separator):

• cid

• origin

The default value is

sip_xheaders=cid:origin

Currently only cid is possible, which is also the default value for this option. Additional future options can be appended using a colon as separator.

If cid is set, a X-BF_CALL_ID Header is added, which contains a bf_cid value, by which the call can be identified on the berofix VoIP Gateway.

If origin is set, a X-BF_ORIGIN Header is added, which contains information about the port, oad, dad and matched dialplan line.

cd

If the option cd=1 has been set on an ISDN->SIP call, a 302 SIP message will trigger a Call Deflection Facility (or Partial Rerouting if ISDN port is PTP). The number contained in the user section of the contact string will be used for the call deflect.

cd_fail_prefix

If call deflection is requested and fails it will be checked for the cd_fail_prefix option. If it is non-empty, the dialed destination number will be prefixed with the value of cd_fail_prefix and the dialplan will be searched again, allowing to match another dialplan rule now.

rtp_traffic_check

rtp_traffic_check takes an integer as value, which defines an interval N.

If the interval is greater than 0, an active call will be checked every N seconds for received RTP packets.

If no RTP packets have been received since the last check, the call will be terminated.

jbopt

jbopt allows to configure some jitter buffer settings of the MSP, if it is not passed, empty or contains invalid values the default values will apply.

• delay_min => 0-300ms (default 0ms) : minimum jitter buffer size

• delay_max => 0-300ms (default 200ms) : maximum jitter buffer size

• delay_init => 0-300ms (default 0ms) : initial delay when voice channel is started

• adaption_period => 1000-65535ms (default 10000ms) : the time period over which the jitter buffer can adapt to changing jitter

• deletion_mode => 0=soft mode or 1=hard mode (default 0) : soft mode puts emphasis on better audio quality on the cost of a slightly higer delay

• deletion_threshold => 0-500ms (default 500ms) : jitter period after which incoming late packets are directly deleted

These six values have to be passed all together as a colon separated string (e.g. jbopt=0:200:0:10000:0:500), if any of these values are missing or are out of range, the whole setting is ignored.

Examples:

jbopt=0:200:0:10000:0:500 would be equivalent to the default settings, with an adaptive jitter buffer size of 200ms

jbopt=40:40:40:10000:0:500 setting delay_min=delay_max makes the jitter buffer non adaptive, this setting would set a fixed jitter buffer size of 40 ms

clir_on_oad

PSTN->SIP

If this config option is set, an incoming ISDN call with an empty oad, or with pres=1 flag set, will have its oad replaced with the given value. So, if clir_on_oad=anonymous, an incoming ISDN call gets its oad set to anonymous, which then can be used in the dialplan. The setting can be applied to incoming GSM and Analog calls too, if the oad is empty. This setting has to be applied in the PSTN port group configuration.

SIP->PSTN

If the outgoing oad matches the value of clir_on_oad, the outgoing oad is set to an empty string, additionally for outgoing ISDN calls the screen and pres flags are set to 1. This setting has to be applied in the PSTN port group configuration.

skip_setup_ack

If this option is set to 1, there will be no ISDN SETUP_ACKNOWLEDGE message as answer to an incoming invite, default is 0;

dialtone_digits

This option can be an integer between 0 and 9. It determines how many digits have to be dialed, before the dialtone is not played anymore, default is 0.

emergency

If this config option is set to 1 in the dialplan, the call is marked as an emergency call. If no free ISDN channels are available, an ongoing non-emergency call will be terminated, to free an outgoing channel.

dnssrv

If dnssrv=1 a DNS SRV lookup will be made for given proxy/registrar. This option has to be set in the SIP port group.

comfort_noise

comfort_noise configures the generation of comfort noise. It can have the values 0, 1 or sdp. If it is 0 (default) no comfort noise will be generated. If set to 1, it will be always generated. If set to sdp, it will be only generated, if succesfully negotiated by sdp. The behaviour of comfort noise generation can be additionally controlled by the vad_tune config option.

vad_tune

vad_tune configures the comfort noise voice activity detector and can take values between 0 and 4. The higher the value, the better the quality, but the lower the bandwidth saving.

• 0: Best bandwidth saving, but low quality for high noise level (default value).

• 1: Less bandwidth saving than option 0. Noise level above “very loud noise” (about 5 dB SNR) is detected as voice.

• 2: Less bandwidth saving than option 1. Noise level above “loud noise” (about 10 dB SNR) is detected as voice.

• 3: Less bandwidth saving than option 2. Noise level above “less loud noise” (about 20 dB SNR) is detected as voice.

• 4: Lowest bandwidth saving. Noise level above “audible noise” (about 30 dB SNR) is detected as voice.

s2s_nat_opener

In a sip to sip transcoding call, the signal processor needs to receive audio on one call leg, to send it out on the other leg. This leads to the problem, that if both call legs are behind a NAT, no RTP will be received until we send a packet first. If s2s_nat_opener=1, RFC2833 DTMF events with invalid payload will be sent on the beginning of audio processing, hopefully opening a hole in the router for the RTP stream.

s2s_t38_passthrough

On sip to sip calls, T.38 is only supported in passthrough mode.

• If s2s_t38_passthrough==0, no T.38 is performed, incoming T.38 invites are rejected.

• If s2s_t38_passthrough==1, incoming T.38 invites are accepted, and if a Fax Tone has been detected, a T.38 re-invite is sent out on both call legs.

• If s2s_t38_passthrough==2, incoming T.38 invites are accepted, but no T.38 re-invites will be sent, if a Fax tone has been detected.

msp_indication_control

With the msp_indication_control setting, the indications the DSP provides can be suppressed or enabled.

Following indications can be controlled:

• RFC2833_DTMF_DET
• INBAND_DTMF_DET
• DTMF EVENTDET
• DTMF TONEDET
• INTVCHNG (Packet Interval Change Indication)
• SSRCVIOL
• SSRCCHG
• PTCHNG
• Periodic PTCHNG Indication Time (in ms)

With exception of the Periodic PTCHNG Indication Time, a value of 0 enables an indication, and a value of 1 disables it. The periodic PTCHNG Indication time can have a value of 0 to 65535 and describes the time in ms, after which the PTCHNG indication is sent, after detecting it.

The default value is for msp_indication_control is

msp_indication_control=0:0:0:0:0:1:0:0:0

That means all indications, except the SSRCVIOL indications are enabled. To disable, e.g. DTMF TONEDET indications in addition to the SSRCVIOL indications set:

msp_indication_control=0:0:0:1:0:1:0:0:0

All 9 tuples must be set, otherwise the whole setting will be ignored.

Call authorization server

A call authorization server can be configured, which can take some call related parameters, and tells the gateway software to ACCEPT, REJECT or REDIRECT a call. This feature currently is only supported for ISDN to SIP calls.

If this feature is used by defining a server with the config option callauth_url a get request in the form:

callauth_url?id=98&caller=1234&callee=5678&gatewayId=12345&direction=INBOUND

where:

• id is an ID referencing the corresponding call

• caller is the number of the originating site

• callee is the number of the destination

• gateway is a 5 digit number identifying the gateway

• direction denotes the direction of the call, currently can only be INBOUND

If the answer to this request is a 200 OK, the answer is expected to have a JSON formatted string as content, e.g.

{"action":"ALLOW","redirectLocation":"11111"}

Only the fields action and redirectLocation will be evaluated, other fields will be ignored.

Facility Messages arriving from ISDN will also be sent to the call authorization server

The get request will have following format:

GET /?id=2&gatewayId=01297&facility=kaETAgIq9QIBIjAKoQUwAwIBAYIBAA%3D%3D&facility_decoded=AOC%3A%20charging%3Bstate%3Dactive%3Bcharging%2Dinfo%3Dpulse%3Brecorded%2Dunits%3D1

• id is an ID referencing the corresponding call

• gateway is a 5 digit number identifying the gateway

• facility is an URL encoded base64 string, which contains the facility message

• facility_decoded is an URL encoded text string, which contains the parsed values of the arriving facility message (so far only AOC and Calldeflect Facilitys are decoded this way)

callauth_url

This option defines the full URL for the authorization service to be used in the GET request, the auth parameters are appended to this URL in the GET request.

callauth_credentials

This option defines login credentials in the form USER:PASSWORD, basic html authentification is used.

callauth_default_policy

This option defines the default behaviour if the authorization request times out, a non 200 answer is given, or if there is no ALLOW/REJECT directive contained in the 200 answer.

It can take either ALLOW or REJECT as parameter. The default is ALLOW.

callauth_timeout

This option defines the time in ms after which a call authorization requests times out. The action defined by callauth_default_policy will be executed.

It can take values between 10 and 1000.

callauth_direction

This option controls the direction parameter in the query to the authentification server. By default it is callauth_direction=INBOUND.

It can take any string up to 32 bytes length.

SIP Headers

For an PSTN->SIP call, there are a range of config settings which control specific Header Values:

• sip_from_display_setting (default: ${new_source})

• sip_from_user_setting (default: ${new_source})

• sip_to_user_setting (default: ${new_destination})

• sip_contact_all_setting

• sip_contact_display_setting

• sip_contact_user_setting (default: ${account_username})

• sip_pai_all_setting

• sip_pai_display_setting

• sip_pai_user_setting (default: ${new_source})

• sip_pcpi_all_setting

• sip_pcpi_display_setting

• sip_pcpi_user_setting

• sip_ppi_all_setting

• sip_ppi_display_setting

• sip_ppi_user_setting (default: ${new_source})

• sip_rpi_all_setting

• sip_rpi_display_setting

• sip_rpi_user_setting (default: ${new_source})

These settings define what comes into the corresponding headers. The settings without a shown default value are by default empty. The all settings define the whole header if they are set and override the settings contained in the display and user config. options contain It can contain any combination of string literals or variables.

Following variables can be used in these headers

• ${new_source}

• ${new_destination}

• ${oad}

• ${oad2}

• ${clip}

• ${cnip}

• ${qsigname}

• ${account_username}