Course10:Basic - PBX - Advanced Object Properties and Behaviour
This book explains more advanced properties and behaviour of the PBX user object as well as their related function keys. Most of them apply to many of the PBX object types.
Call Forwardings
Btw: call diversion and call forwarding are often used as synonyms.
Calls to Objects with no Endpoint registered to
An innovaphone PBX has all the call forwarding types known from legacy PBX systems. A special case though is a call to an object where there is no endpoint registered at all for. This situation triggers the CFNR.
Rejecting Calls
Users can reject alerting calls on the phone (depending on the phone e.g. by pressing the disconnect key). This will trigger a CFB.
Forwarding Loops
For example, in a simple scenario where there are extension 10, 20, 30 and 40 and there are CFUs like
Object | CFU |
10 | 30 |
20 | 40 |
30 | 20 |
40 | 10 |
When 30 calls 20, the call will ring at 10, although there is a CFU on 10. This is because executing this CFU to 30 would close the loop. And is thus ignored.
Conditional Forwardings
CGPN
When an Only or Only Not rule is configured for a call forwarding, the call is only forwarded if the start of its source number matches the rule's No entry (or the calling name, which is the calling objects Name property value, entirely matches the rule's Name entry).
The calling number provided with the call as well as all the diverting numbers are matched against the rule's No.
Internal / External Calls
Although external calls could be matched as Only From 0, calling numbers are not always safe. External calls can be matched better using the Ext. / Int. switch.
Dynamic Conditions
The call forward is triggered only if the condition described in the boolean object is met (or is not met, if the Not check mark is ticked too).
Implicit Forwarding
This is a convenient way to configure the handling of standard call forwarding situations such as CFB (Busy) and CFNR (No Answer) globally. In addition, special situations like calls to incomplete (Incomplete) or wrong (Invalid) extensions can be handled.
Most of those implicit forwards are of course optional, the PBX works fine without setting those. However, one of them, Loopback, you will want to consider for sure! If you don't set this, external callers will be able to call in to your PBX and straight call out to the trunk again. This way, you will bear the cost!
Note that implicit forwarding settings apply to calls through (that is, from) the trunk object to local extensions whereas call forwarding set on the trunk apply to calls to the trunk!
Disabling Forwarding
Any call forwarding can be disabled explicitly by configuring a minus (-) as call forwarding destination. This does make sense for CFNR and CFB only.
This will also disable implicit forwardings imposed by the trunk object.
This feature is essential on fax lines when you set Busy (CFB) or No Answer (CFNR) globally on the trunk line. If for example, such calls are forwarded to the switchboard, an incoming fax to a busy fax device will be forwarded to the switchboard too. This will probably not make the receptionist happy! You should then disable call forwards of both types for the fax line.
Object Specific Handling of Call Forwarding
For example, a CFB set on a trunk will not trigger when the trunk already has an active call as a CFB on an user object would. Instead, it is triggered when the object called through the trunk (usually an external number) is busy. You should refer to the Call Diversions section for the respective objects for details.
Setting Call Forwarding on the Phone
However, for end users, it is much more convenient to set them directly from the phone. As H.323/H.450 defines a standard to communicate call forwarding settings between an endpoint and the PBX, H.323 based devices can be used for this. innovaphone phones allow end-users to do this through the Menu / User Setup / Call Diversion menu. Default forward destinations can be set in the Favorite Diversions properties of the phone's
However, only basic call forwarding settings can be set this way. Conditional forwarding properties can not. As they can't be set, they are not shown on the phone either. This is why such call forwarding settings are referred to as administrational call forwards sometimes. When set in the PBX, they are not shown on the phone and cannot be changed or deleted from the phone. In V10 users can set non-conditional call forwards types from within myPBX.
In SIP, there is no such protocol available and some SIP endpoints will instead perform limited call forwarding procedures autonomously. Setting the PBX's call forwarding settings is not possible thus.
Up to 4 independent forward settings can be defined. Users can then toggle through those settings by pressing the function key.
The current status of the call forward setting is retrieved from the PBX and matched to the defined sets. If none matches, the idle state is assumed.
This feature is not available when the phone is registered via SIP.
The CFNR Timeout
Limiting Call Forwarding
This allows for example to disable costly call forwards to external recipients (such as mobile phones).
Call Transfers
A blind transfer is initiated using the redial key on the phone. The call is redirected to the new destination right away and thus disappears from the transferring phone.
For a consultation transfer (which is available in connected state only), the call is put on hold, a new call is placed to the intended destination. The 2 calls are then transferred by either putting the receive on hook (transfer by on-hook can be disabled by setting the No Call Transfer on Hook-On property in the
When a consultation transfer is initiated while the consultation is still in alerting state, it is sometimes referred to as semi-blind transfer.
The Redirect Function Key
By default, when there is an active (connected) call when the function key is pressed, the redirection is performed on the first waiting call. This is convenient to get rid of call waiting on a call-by-call basis (as opposed to setting a CFB).
If the Redirect Active Call property is set in the function key configuration, the active call is redirected instead.
The Recall Timer
Controlling external Transfers
This is because such transfers would create calls which impose costs on the owner of the external trunk line. At the same time, as they disappear from the transferrers phone, they cannot be controlled any further.
To allow external call transfers, you need to enable the Enable External Transfer check-mark on the PBX's
Filter
A filter defines a set of number prefixes which are matched against the called party number of a call. They can be made dependant on the current status of a boolean object at match time. If one of the numbers matches the head of the called number, the filter is applied to the call.
This can be used for restricting call destinations for PBX (user) objects and to limit call forwards set for an object. For example, you would define a filter that disallows calls to the local trunk line on non-business hours and apply it as Filter setting to individual PBX (user) objects to make sure users need to place external calls through the switchboard then.
Another use of filters is for the prevention of call forwards. You would apply the same filter as Diversion Filter to make sure external call forwards are disallowed outside of business hours.
Filters are generally checked at execution time, not at configuration time.
Disallowing incoming external Calls
A common case of restricting incoming calls is to disallow direct calls to an extension from external. This can be achieved by simply setting the Reject ext. Calls check mark on the user. Note that in this case neither CFNR nor CFB are triggered, but CFU is honoured. Also the rejected call will trigger the Invalid destination property defined in the Trunk Line object.
Manipulating the Number sent
Changing the CGPN
It is possible to change the CGPN by setting the Send Number property of the calling object.
In a help desk scenario, you may want to set the Send Number property to the help desk number for all agents to make sure individual extensions are not sent to called customers.
Suppressing the CGPN
As an alternative, a call can be initiated with the calling line id explicitly suppressed. This must be done by the calling endpoint (i.e. the phone). There are several options to do this.
Setting the User Default
In the Menu / User Setup menu of the phones, the Number Presentation entry will set the user's default for the calling line id suppression. This is also available in the
Using a Function Key
An equivalent setting can be done by configuring a Hide Own Number function key in the phone's
Call by Call
When using prepared dialling, pressing the menu key before the call is actually initiated will show a context menu on the phone that allows to turn the calling line id on and off for this call.
Limit the Number of concurrent calls
This is useful to cope with devices that do not handle call waiting situations gracefully.
Please note that when is Busy On ... Calls set to 1, there will be no call waiting situation on the user's device, as the extraneous calls are never sent to the device. As a result, such calls will also not be listed in the devices call list! It is thus generally not recommended to use this setting for users with innovaphone telephones. They should rather be handled using the phone's call waiting configuration (see next chapter).
Gateways
If the object is of type Gateway or Trunk Line, then calls both from and to this object will be counted extraneous and rejected. This effectively limits the total number of calls at any point in time for the endpoints registered.
Call Waiting
The Call Waiting property in the phone's
The Call Waiting function key allows the user to turn call waiting on and off conveniently. Call waiting is turned off in idle state.
Twin Phones
To handle this scenario, set Twin Phones in the user's object properties. If so, additional calls are signalled to the currently busy phones only, leaving it to this phone to handle the call waiting situation.
Transfer between Twin Phones
However, when a twin phone calls itself, the call is not sent to the calling phone but to all others registered to the object. This allows a user to transfer a call from one of his twin phones to another (e.g. from the fixed line phone to the DECT leave the desk while keeping the call).
Do not Disturb
In DnD mode, the phone will not ring on incoming calls. There are various modes available, either in the Action area of the Do not Disturb function key configuration or in the Do Not Disturb area of the phone's
The modes include the option to send an absent message to callers while the phone is in DnD mode. This message can also be defined via the phone's Menu / User Setup / Do not disturb / Out of Office Msg. menu.
Hiding an Object from the PBX Directory
Directories are used whenever an outgoing call is initiated with a name dialled instead of a number. Even more, the directories are searched for a matching number when an incoming call without name identification is received.
Sometimes however, the object information should rather be hidden to other users so that they cannot locate the object via the directory. In this case, set the Hide from LDAP object property.
Applying basic Properties to a Number of Objects
Templates can be nested.
Managing Phone Configurations
This is why the user-specific part of the phone configuration can be stored in the PBX. To enable this feature, tick the Store Phone Config check-mark in the user object's User configuration tab. You will then find a link config in the Phone column of the PBX's
Normally, any existing configuration on a phone is retrieved and saved in the PBX's phone configuration. However, it is possible to discard any phone configuration. See the Store Phone Config and Discard Config on Phone properties for more details.
Using Templates for Phone Configurations
If the user itself has a phone configuration stored in the PBX, the template's and the user's configuration are merged and then applied to the actual phone.
Finally, a configuration template can inherit up to 4 other configuration templates. This can be used to build a template tree.
Groups
A group defines a set of PBX objects that in some way belong together. A single object may belong to many groups.
Group membership can be active or passive. When a group member is active, then it somehow knows about the other members in a group. Whereas a passive member has no knowledge of the other group members.
Consider 5 objects which are member of the same group. 2 of them are active.
Group Membership Types
User 1 and User 4 know about the other objects as they are active members of the group. All others don't.
Objects can be active member in one group and passive member in another. Objects can also be active members of more than one group. Group membership alone does not do anything, neither passive nor active membership. However, groups are used to configure various other features.
Groups are limited to 2000 members. Don´t use existing "Name" for group name.
Group Pickup
There are several ways to do this.
Pickup using the DTMF Object
It is also possible to pickup a specific call if more than one are currently alerting. This is done by dialling the *0*<user># feature code, where <user> is the extension of the object the call is alerting on.
For innovaphone IP phone users, it is usually better to use the Pickup or Partner function key. The DTMF feature is useful for H.323 devices that do not support call pickup, for SIP devices and for non-IP devices, such as DECT phones.
Pickup using the Pickup Function Key
When in active state, the alerting call will be signalled to the user (there are several options available like turning on an LED, issuing an audible alert or hiding the involved party numbers). When the function key is used in active state, the PBX will send the call to be picked to the picking phone too. The user can then examine the detailed call info presented with the new call and decide whether to really pick the call or not. This is in contrast to how the DTMF object works, as this will connect the picked call right away.
For this to work, the picking phone must be aware of all pick-able calls of course. This is done by setting the Group Indications property in the picking users PBX object configuration. This property is set to the name of a group the picking user object is an active member of. The PBX will send status information for all objects that are known to the picking user object due to the group membership.
Group Indications
Group memberships can become quite complex. It is a common configuration mistake to configure a Pickup function key but no appropriate group indications.
The Partner Function Key
Just like with the Pickup function key, the user that has the Partner key defined on his phone normally needs to have a proper Group Indications in his own PBX user object defined.
When a call alerts at the partner object, the function key will signal it and pressing the key will have this call alert on the users phone just like with the Pickup key.
However, the Partner function key can do much more.
Monitoring the Partner's Busy State
Monitoring the Partner's Presence State
Busy vs. Presence State
A user's presence state is different from his busy state. The busy state includes phone usage information only, that is, if the user has call, if it is alerting or connected, which numbers are involved. The presence state instead only has a condensed notion of the user's phone activity (the so-called on-the-phone state element). However, in addition to that, further information such as an activity (lunch, meeting, vacation...), a user defined note or the general ability to receive instant messages may be included in the presence state. In fact, presence states can be utterly complex, but most software currently available will only make use of the elements mentioned.
In the PBX, the users presence state can be edited in the Presence column of the
Obtaining States
There is however another huge difference between busy and presence state. The busy state is sent proactively to interested parties. This is controlled by the group configuration discussed before.
The presence state however is requested by interested parties. So when a Partner function key has the Subscribe for Presence check-mark set, it will send a request to that effect to the target user's PBX. There is no need to touch the PBX configuration for this to work. The only thing to make sure is that the requesting user has the right to see the target user's presence state. This is configured in the Access column of the PBX's
Also, as the requesting party sends a request to the target users PBX, obtaining the presence status works cross-PBX (although in this course you will not deal with multi-PBX configurations). Group indications are sent only between users registered with the same PBX!
The presence state will also be sent back to a user calling the object. The calling user will see the status in his phone's status line while the call is alerting.
A second way of defining Access Rights is by using groups. Access rights are implicitly assigned to active users of a PBX user group. Active group members can see the presence and call information of other users in the group. Group Indications are not needed in this case, since the group-information is displayed on a phone by using the Subscribe for Presence mechanism explained before.
Access rights assigned to users/groups/domains by means of a Config-Template or by the user himself, overwrite access settings inherited by groups.
The recommended way of granting users access to your presence is by using Access Rights.
Using Dialog Info as an Alternative to Group Indications
Dialog Info is used to obtain the partner object's busy state when the Subscribe for Dialog Info check-mark is ticked in the the Partner function key definition. If so, no group indications are required or used any more for this function.
From V9 on, this is the recommended method to implement the partner key. However, for compatibility reasons, the method based on group indications is still valid.
Again, similar to the previous chapter, you can use groups to define Access Rights.
Calling the Partner and Intrusion
The function key can be configured such that when the partner is already engaged in a conversation, the call is initiated as an intrusion call ( Perform Intrusion if Partner is busy). An intrusion call connects immediately and creates an implicit 3 way conference between the active call before the intrusion and the intrusion call. The intruder is then part of the intruded call.
By default, both parties of the original call will hear an intrusion tone. This can be disabled though using the No Local Intrusion Tone property in the
The Partner function key can be configured such that the call is silently intruded to. Instead of creating a 3 way conference, this intrusion type will create a uni-directional channel from the intruded phone to the intruder. The intruder will not be heard by the original call parties and no intrusion tone is sent. This type of intrusion is configured by selecting Silent Monitoring as the value for the Type property in the Partner function key configuration properties.
Call intrusion needs to be enabled using the Enable Call Intrusion property on the calling phone's
The Dial Function Key
By default, when a call is present, the previously active call is put on hold and a new call to the destination is created. However, when the Send in Active Call property is set in the function key configuration, no new call will be created in this case. The digits from its Number property are sent within the current call instead. If the call was already connected, the digits are sent as DTMF. If not, the digits are sent like single digits sent in overlapped dialling mode.
When no call is present, and the Prepare property is set in the function key configuration, the phone will go into the prepared dialling mode just like as if you had dialled the digits of the destination number on the phone's keypad. You then have the chance to edit the number before you go off hook and initiate the call.
Announcement Calls
For this to work, announcement calls must be enabled in the Allow Outgoing property of the Announcement Calls area of the calling phone in the phone's
By default, the announcement call is connected and the destination phone's microphone is turned off. This way, silent surveillance of a room is inhibited. If surveillance is desired, the destination phone needs to set the Micro On property.
A phone can be configured to accept any call as an announcement call, even those that have not been initiated as such. This can be done by setting the Treat Incoming as Announcement property for this phone.
Any announcement call takes precedence over currently active calls (except if the currently active call is an announcement call too). That is, any currently active call on the destination phone when an announcement call comes in is put on hold and the connected announcement will become the active call.
Call Parking
Parked calls differ from held calls in that they disappear from the callers phone completely as long as they are parked. Also, other users can un-park the parked call which then looks much like a call pick-up. This allows calls to be moved between users without a call being made between source and destination (in fact, the source doesn't even need to be able to call the destination).
When no park position is specified during park or un-park, the park area is treated like a queue.
Park using the DTMF Object
If the call is to be parked to another PBX object, feature code *17<position><target> and #17<position><target> will do.
Like with all DTMF object features, this will work with just any phone.
The Park Function Key
Any un-parked call will appear as an alerting call (just like when picking a call) on the callers phone. However, if you decide not to un-park the call by pressing the disconnect key, the parked call will be disconnected and the previously parked party will see a user busy indication.
The Park function key will work only if the user receives group indications from the object the calls are parked to (that is, the object defined by the properties in the Park Destination area of the function keys configuration).
Line Key Feature in the Trunk Object
This allows other users to configure separate Park function keys for each available B-channel in the Trunk Line object. These would specify the Trunk Line object in the Park Destination area of the function key configuration. The Position property would be set to ascending numerical values starting with 0.
With these keys - a.k.a. as line keys - a line can be acquired, monitored, a call can be parked on the line and un-parked up from the line. This effectively simulates an old style line-key telephone system.
In such cases, you should enable the Trunk Line flag, a new option which synthesizes the behaviour previously obtained using Park Active Call before Unpark and Automatic Connect after Unpark from Version 7.