Reference8:Administration/PBX/Objects
This page is used for the administration of PBX objects. A list of already configured objects can be displayed filtered by various criterias. New objects can be created and existing objects can be changed or deleted.
Display of existing Objects
By pressing the show link, existing objects are displayed. With the filter field (the input field left to the show link) the displayed objects are limited to those matching the filter. The filter is first applied to the 'Long Name' of the objects meaning a non case sensitive head match of the filter and the 'Long Name' is performed. If there are matching objects these are displayed.
If there are no matching objects the filter is used to match the Number of the objects including any node prefixes. This way objects of a given node with all subnodes can be displayed by entering the prefix of a node here.
Below the filter input field is a list of all PBXs in the system (at least the part of the system which is replicated to this device). By clicking on a PBX in the list only the objects which are assigned to this PBX are displayed and the groups configured on this PBX are displayed as well. By clicking on a group only the members of this group are displayed.
List of Objects
On the right side the list of objects is displayed. The most important configuration properties are displayed in this list to provide an overview. To view the full configuration of a given object it must be opened for editing by clicking the Long Name. The list can be sorted by clicking the table headers.
The Number of the objects in this list is not the number configured in the object but it is expanded with the prefixes of the nodes in which the object is configured.
Group memberships and Call Forwarding for an object are changed by clicking on the 'Groups' or 'CF*' link of the object. A '*' appended to a group displayed in this list means that the active flag of this group membership is set. A '!' appended to a group displayed in this list means that group indications are configured for this group.
Fork number appended by a '*' indicates a mobility enabled user. In case the number is displayed in grey, the user consumes no mobility license on local PBX (e.g. because the user registers on other PBX).
The last column are the IP addresses of registered endpoints for a given object. If the physical location of the endpoint is not the same as the PBX, the physical location is indicated by @<physical-location> added to the IP address. A '*' appended to this field means that this is an password authenticated registration. Registrations which are because of a standby situation, which means they are not at the PBX for which they are configured, are marked with a special colour (by default this is red).
New Objects
New objects are created by selecting the type of object in the drop down list and clicking the new link. If the list of displayed objects is limited to a PBX/Group (see above), the PBX property of the new object is preset accordingly and the group membership is added to the object.
Object Properties
* Note : never use special character "@" in any Object (Name, Long Name, Display Name), see also Support:Using @ in the Objects Names considered harmful in Master Slave Scenarios .
Depending on the type of the object different configuration parameters are available. Some configuration parameters are common for all objects.
| Long Name | This name is used to identify the object in the database and for display purposes. The long name must be unique throughout the system. For practical reasons, you should limit it to 20 - extension length characters. |
| Name | The name of the object. This name is used for signalling (like a call number) and must be unique throughout the system. Note that from V8 on, clients cannot use the Name property as registration name. They must use one of the devices (see below). Likewise, for those objects that have a Number property, when a registration is attempted using this number, the corresponding object is looked up, the Name property retrieved and a registration tried. As a result, the registration will fail if the object does not have a device with a hardware-id identical to the objects Name. |
| Hardware ID | The Hardware Id from v7 is replaced by the Devices configuration (see below) |
| Node | The node that the object is assigned to. A Node hierarchy can be configured using Node Objects. Objects which are assigned to the same node can call each other with just the number. To call an object in a different node escapes and node prefixes have to be used. If no node is configured, the object is assigned to the node of the respective local pbx. See Reference8:PBX Locations. |
| PBX | The PBX that the object is assigned to. This PBX accepts registrations for the object. If no PBX is configured, the object is assigned to the respective local PBX. |
| Local | Marks an object as local. Local means that it can be called from endpoints physically located at the same PBX without prefixes even if the calling endpoint is in a different node. Where the endpoint is physical located is defined by the PBX the endpoint contacts first (it may be redirected to another PBX then for registration). If the object does not have a PBX configured the call is routed to the PBX where the calling endpoint is registered. |
| Send Number | If an object does a call, the calling party number for this call will be replaced by the number given (if any). Used to hide an extension. Currently works for non-gateway object types only. |
| Password / Retype Password | If a registration password is allocated here, then it must be specified during registration, or otherwise the registration will fail. |
| Filter | The filter configured here restricts the numbers which may be called by a endpoint registered to this object |
| Diversion Filter | The filter configured here restricts the numbers which calls may be diverted to by a endpoint registered to this object. The Diversion Filter prevents the setting of a Call Forward to specific destination via an IP-Phone or myPBX, but do not prevents the execution of already configured Call Forward. |
| Reject ext. Calls | If this checkmark is set a call from an external source to this object is rejected. A calling party numbering plan private is used to decide that the call is coming from an internal source. An invalid number destination is excuted for calls rejected because of this. |
| CFNR Timeout | Overides the PBX global CFNR timeout for this object |
| Busy on n Call(s) | If this value is set a call to this user object is rejected with User Busy if n or more calls are active on this user object. If the object is of the gateway type (Gateway, Trunk, ...) calls from endpoints registered to this object are rejected as well in this case. |
| Twin Phones | With this checkmark the twin phone mode is enabled for this object, which means that one user uses different phones. The main difference is, that if one phone is busy and additional call is sent to the busy phone only as call waiting and not to the other phones.
If "Call Waiting" is disabled on the busy phone a second call gets a busy tone and a missed call is displayed when the active call is terminated. |
| No Inband Disconnect | If this checkmark is set, a call disconect with inband information will not be forwarded to the endpoint registered to the user, but the call will be cleared immediatelly without the inband information beeing sent. |
| Store Phone Config | If this checkmark is set, the PBX stores the config of the phone. The first time a phone registers the predefined config at the PBX is sent to the phone even if it is empty. Then the local config stored at the phone is merged into the received config and the result is returned to the PBX. After this the local config is deleted and no local config is stored on the phone anymore. Later config changes on the phone will be sent to the PBX and stored there. On registration the PBX sends the complete config to the phone again. |
| Discard Config on Phone | If this checkmark is set in addition to Store Phone Config the local config stored at the phone is discarded but not returned to the PBX when the phone registers the first time, i.e. the phone is configured with the config predefined at the PBX. This checkmark should be activated during normal PBX operation. When migrating from a system with phone based config to PBX based config it might be required to disable the Discard Config on Phone flag. After the migration from local stored to pbx stored phone config is complete, the Discard Config on Phone should be re-enabled. |
| Group Indications | The group for which group indications are sent to the registered endpoints. The object must be active member in this group. The other objects (for which group indications are sent) need not to be active. To monitor other endpoints on a phone with a Partner/Pickup function key group indications are needed for the endpoints. The maximal length of the Group Indication Name in V7 is set to 48 characters. |
Devices
With the devices configuration it is possible to identify the different devices, which may register for a user. The Hardware Id is used to match the incoming registration. The Text can be used for a description of the device. On the SOAP/TAPI interface Text can be used to let the user select the device which shall be controlled. If no device is configured the Name and v7 Hardware Id are used for default devices to ensure v7 configuration compatibility.
To allow an endpoint to register with the objects Name or Number, a device must be configured with a hardware id identical to the object Name.
Objects with empty node or PBX
If an object has no PBX configured, it will be replicated (if replication is turned on) to all slaves. Furthermore, any PBX will satisfy incoming registration requests. Calls to such objects that are built-in to the PBX and thus do not require a registration to work (e.g. Waiting Queue) will be processed by each PBX the call is presented to.
If an object has no Node configured, it will be considered to live in the node of each PBX is known to. So if an object has neither Node nor PBX configured, it will be present in all nodes that have a PBX and calls to such objects will be processed locally for objects that are built-in to the PBX.