Help on timers for re-routing, recall and forwarding

  1. Scenario A: Call comes in on trunk hits nupoint AutoAttendent,
    option 1 is choosen and call is blind transfered to an extension.
    After a time of no answer the call is “recalled” to the AutoAttendent.
    Which timer is used: As the call in on the trunk it uses the COS of the trunk.
  2. What timer is used for “MultiCall delay-ring”? It uses the phones COS option “Delay Ring Timer”
  3. When using Re-route “first alternative” which timer is used? The phones COS “Call FWD no answer timer”
  4. When using Re-route “Second alternative” which timer is used? System options/Call Re-routing Timer

MCD-NoAnswerRecallTimer MCD-CallFWDNoAnswerTimer MCD-CallRerouteTimer MCD-DelayRingTimer

 

The COS “Call Forward – No Answer Timer” determines the length of time a call will ring a station before it is forwarded to the next programmed destination. The timer is reset each time the call is forwarded.

The System Option “Call Rerouting Timer” determines the length of time from initial call setup until the unanswered call is rerouted to the destination programmed in the Call Rerouting Second Alternatives form. The timer remains active through all COS-controlled call forward programming that may be activated at the destination station

 

More help

Sources

Assuming SX2K or 3300:

If the key appearance is also a PRIME number on a set somewhere then it’s call rerouting on first alternate will be controlled by the COS of the set where it is prime.  Call reroute second alternate will always be controlled by the call rerouting timer in the system options assignment form. 2nd alternate destination is not controlled by class of service.

With no call reroute 1st or 2nd alternate, then user-programmed forwarding (if any) takes over. However, user-programmed forwarding only applies to the PRIME number. In this case the amount of ring time on each instrument in a daisy-chained string of multiple forward hops will be determined by the COS of each set in the chain. With daisy-chained user-forwarding all forward hops must be prime numbers except the final destination can be a softkey.

Black magic comes into play when we begin dealing with extensions that are not prime (anywhere) and appear only as softkey appearances.

In the first place, key appearances that are softkeys only and do not have a prime appearance anywhere cannot be user-forwarded, period. Please note the period. They can only be rerouted via the call rerouting tables.

However, CLASS OF SERVICE still comes into play. What determines the class of service of a “softkey” is the class of service assigned to the instrument where the softkey first appears. To find out, look at the MULTILINE SET GROUP (MU S G) assignment form for the softkey extension you’re interested in. This form will show the PRIME EXTENSIONS of all sets where the softkey appears. The first set in the list is the one that governs class of service behavior of the softkey.

Leave a Reply