CFU (call forward unconditional) is a procedure diverting all incoming calls unconditionally for the programmed MSN and basic service. The call will never be announced at your side until CFU is deactivated again.

CFNR (call forward not reachable) is a procedure diverting all incoming calls for the programmed MSN and basic service after locally signalling and waiting a certain timeout period. If the call is not answered during this timeout period it will be diverted to the new destination. The timeout period is fixed in the providers exchange and is normally 3 rings (about 12 to 15 seconds).

CFB (call forward busy) is a procedure diverting all incoming calls for the programmed MSN and basic service when all local resources taking the call are exhausted and busy.

Activate a static diversion for the given driver, msn and service diverting the call to the specified destination. All parameters need to be supplied, no wildcards are allowed. Only one of the three diversion procedures cfu, cfnr, cfb must be supplied. The value for the service may be taken from the table of numeric codes of basic services. The value 0 specifies all available/subscribed services.

deactivate driverid <cfu,cfnr,cfb> msn service

Deactivate a static diversion for the given driver, msn and service. All parameters need to be supplied, no wildcards are allowed. Only one of the three diversion procedures cfu, cfnr, cfb must be supplied. The value for the service may be taken from the table of numeric codes of basic services. The value 0 specifies all available/subscribed services.

interrogate driverid <cfu,cfnr,cfb> [msn] [service]

Query static diversions for the given driver, msn and service. Only one of the three diversion procedures cfu, cfnr, cfb must be supplied. The msn and service parameters are optional. The value for the service may be taken from the table of numeric codes of basic services. The value 0 specifies all available/subscribed services. If msn and/or service parameters are not specified all matching diversions are reported via stdout. But it is advisable always to specify all parameters to keep the list as short as possible. All known providers exchanges refuse to return diversion lists longer than 256 bytes. In this case an empty response is generated by the exchange even if there are diversions active !

Dynamic Call deflection is controlled by a rule chain the user has to supply using the divertctrl program. When an incoming call arrives, calling data is compared against the rules in the chain. If an incoming call matches a rule, this rule is taken to execute the desired action. All following rules are ignored. If there is no rule match the diversion services simply ignore the call.

appendrule driverid action msn si1 si2 callerid screen delay option destnumber

This command appends a single rule at the end of the existing rule chain. If the call arrives through the desired driver, addresses the selected msn, si1, si2 and matches the desired callerid and option the specified action is executed. A value of - may be specified for the driverid to match the rule for all available drivers. The msn may be specified with a trailing - wildcard. for example the value 123 only matches an incoming call to msn 123, but specifying 123- matches all msn starting with 123 followed by any digits or subaddresses which will not verified. If only - is specified the rule matches all msn and subaddresses. If your isdn line supports subaddressing it is advisable to terminate all msn values with a - because the msn check includes a possibly available subadress which then may be reported as 123.456 for msn 123 with subaddresses 456 for example. Subaddressing is a special DSS1 feature not available in most countries and normally needs to be specially subscribed. So most people need not to think about it. The value of si1 represents the numeric code of the desired and checked basic service for the incoming call. This value may be selected from the table below or just the value 0 specified for all services to match. The value of si2 represents an additional service indicator for high layer compatibility and is only included for completeness. Just set it to 0 at the moment. The callerid must match the number of the caller including the subaddress if available. Again the special wildcard - may be used to match specific groups of numbers. Additionally a simple value of 0 may be specified. In this case the rule will match only calls coming in without a caller indentification. This will be the case if the caller originates from a network not supporting callerids or the caller suppressed the identification. The option parameter may take the values 0 to 2 and specifies whether the rule applies only during special local busy states. The value of 0 lets the rule be valid during any local busy state. A value of 1 lets the rule only apply to incoming calls if the call is in a non waiting state. A value of 2 applies te rule only to such calls which arrive as waiting. This is normally the case when all local resources (B-channels) are already in use. If the rule criterias mentioned before match the incoming call, no following rules will be checked and the desired action will be executed. The value for the parameter action is numeric and may take the values 0 to 5 at the moment. A value of 0 lets the call to be ignored. The call will not be reported through the ascii interface and not checked against any following rules. A value of 1 will report the call through the ascii interface but no other action will take place. If the value 2 is specified the call will be reported through the ascii interface and actively put in a local proceeding state. This means that the providers exchange is told, that your side needs more time to check whether the call may be handled and in which way this will be done. This value only is intended for use with local or remote client software watching the ascii interface and deciding what to do. No ringing signal is send to the caller until the decision has been made or a timeout (typically 5 to 15 seconds) occurs. An example would be a software which announces the call to a user and requests the desired action. At the moment a client software is under development, but still not available, so this value may only be interesting for programmers which want to write their own client. If value of 4 is specified the call will be actively rejected. The value of 5 is not primary an diversion function and allows an i4l network device to be started for dialing out when the rule matches. The destination number parameter specifies the network device (for example ippp0) to e dialed. The incoming call itself is not accepted. The values from 0-2 and 4 don't require a destination number to be specified, as the incoming call will not be deflected in this cases. The last, but most interesting value for most people will be the value 3. Specifying it, will let the call to be deflected/diverted actively. For this reason additional parameters are taken for interpretation. First of all destnumber specifies the final number the call should be diverted to. The parameter delay specifies after how many seconds the call will be diverted towards the new destination. A value of 0 deflects the call immediately like the cfu in static diversons, any other value first announces the caller a ringing state until the time is elapsed and then the call will be diverted like in static cfnr. During the ringing phase every other device on your line may pick up the call of course. The value of the parameter screen may take the values 0 to 2 and specifies if the diversion is presented to the caller. A value of 0 denies to show the caller that and where the call has been deflected. Specifying a value of 1 only shows that the call has been diverted but doesn't show to which final destination this will happen. A value of 2 lets the caller know all information of the diversion (fact of diversion and number diverted to).

insertrule driverid action msn si1 si2 callerid screen delay option destnumber

This command inserts a single rule at the beginning before the first already existing rule in the chain. All parameters and descriptions are the same as for the appendrule command.